Вопрос касается ссылок на фреймворки с открытым исходным кодом. Их много для разных целей. Я лично использую несколько из них в одном проекте. Например:Copy Paste v Ссылка
- Unity
- CAL/Prism
- ValidationAspects
- EnterpriseLibrary Вход
- EnterpriseLibrary Обработка исключений
- EnterpriseLibrary Кэширование
- Caliburn
Все эти рамки значительно помогли с точки зрения усилий в области развития. Однако есть некоторые негативные аспекты:
- Тонны библиотек (15 из вышеприведенного списка).
- Уровень приложения (не общие сборки и новые сборки) должен ссылаться на многие базовые dll, которые могут сбивать с толку), и задействовано множество различных пространств имен.
- Развертывание данных тонких библиотек может стать проблематичным (иногда я использую ILMerge для облегчения этой и вышеупомянутых проблем, но давайте отложим это на время).
- Срок действия проекта с открытым исходным кодом - проекты с открытым исходным кодом приходят и уходят, поэтому, если какая-либо из них перестает активно поддерживаться, это может быть связано с наличием внутренних ошибок, требующих исправления или улучшения, которые мы хотим.
- Обфускация «как делать вещи». Мы не активно используем все части вышеуказанных структур. Фактически, некоторые из этих структур имеют перекрытие и обеспечивают избыточные компоненты и функциональность. С точки зрения развития это может сбить с толку. Мы хотим, чтобы последовательная реализация была простой и понятной в нашей базе кода. Наличие нескольких областей, которые делают одно и то же по-разному, может быть проблематичным в этом отношении. Это, наверное, одна из моих самых больших проблем.
- У вас большие проблемы, если эти фреймворки ссылаются на разные версии других сборок (т. Е. Внутренне ссылаются на Unity 1.1 и еще один Unity 2.0).
Альтернатива? Включите исходный код в общую dll для ваших проектов (например, MyProject.Common). Давайте пока отложим вопрос о соблюдении требований к лицензии.
Это имеет несколько негативных последствий также:
- Это не так легко использовать обновление, выпущенное компанией поставщиком фреймворки - вам необходимо обновить исходный код.
- Инкапсуляция функциональности - это легче разбить эту парадигму, когда исходный код находится в ваших руках.
Итак, я знаю, что люди, вероятно, имеют много мнений об этом ... и я хотел бы их услышать.
Спасибо.
Можете ли вы или кто-нибудь еще прокомментировать причины не просто включать исходный код для фреймворков с открытым исходным кодом в свой собственный исходный код? – Jeff
ОК, добавлено несколько причин. Удачи! –