Разработка библиотеки классов / общей библиотеки внутри компании?

Question

Существуют ли какие-либо руководящие принципы / лучшие практики по разработке библиотеки классов (настраиваемой внутренней "корпоративной библиотеки") или проекта или решения с общим исходным кодом или несколькими проектами, возможно, в рамках небольшой или средней компании, занимающейся веб-разработкой (~50 сотрудников)?

В настоящее время существует один проект, который включает в себя весь "повторно используемый" код и может быть включен в новые проекты. Проект далеко не "тяжелый", но код также не связан логически, это просто большая куча ранее созданных функций. Какие вопросы нужно задать, чтобы решить, насколько это хороший подход?

Answer 1

Рекомендации / рекомендации по разработке библиотек классов: http://msdn.microsoft.com/en-us/library/ms229042.aspx

Вы можете уточнить? Что именно вы имеете в виду, когда говорите "... это просто большая куча ранее созданных функций"?

Answer 2

Похоже, у вас большая сборка, в которой есть все общие функции (поправьте меня, если я ошибаюсь).

Как и в большинстве случаев, у этого подхода есть свои преимущества и недостатки, которые зависят от ваших потребностей.

В ("устаревшей", но, вероятно, все еще актуальной) статье " Повышение производительности управляемого кода" на самом деле рекомендуется "Предпочитать одиночные большие сборки, а не несколько меньших сборок". Я не уверен, будет ли какое-либо влияние на производительность заметным. Если бы они были заметны, я бы подумал, что это будет только при запуске.

Даже если весь ваш код находится в одной сборке, я бы порекомендовал логически разделить функциональные области на отдельные пространства имен. Ваше использование слова "куча", кажется, подразумевает, что это может быть не так.

С положительной стороны:

• Добавить ссылку на одну сборку легко
• Развертывание может быть проще, поскольку требуется развернуть только одну сборку (сложнее запутаться?)
• Потенциальные улучшения производительности

С отрицательной стороны:

• Если 90% ваших пользователей используют только 5% реальной функциональности, то может не стоить загружать всю сборку
• Одна сборка может усложнить соблюдение архитектурных / проектных стандартов. Например, если уровень пользовательского интерфейса не должен напрямую взаимодействовать с уровнем данных, вероятно, не имеет смысла предоставлять доступ к общим функциям доступа к данным. Одна сборка может упростить обнаружение такой "ошибки". "Почему вы ссылаетесь на сборку доступа к данным из пользовательского интерфейса?"

Как я упоминал ранее, я думаю, что более важной, чем фактическая упаковка сборки, является логическое группирование функциональных возможностей в этой сборке. В вашей сборке Enterprise.dll я ожидал увидеть несколько пространств имен, которые организовали функциональность. например, Enterprise.Logging, Enterprise.Caching, Enterprise.Validation, Enterprise.DataAccess, Enterprise.Security и т. д.