2010-05-17 2 views
2

Вопрос касается ссылок на фреймворки с открытым исходным кодом. Их много для разных целей. Я лично использую несколько из них в одном проекте. Например:Copy Paste v Ссылка

  1. Unity
  2. CAL/Prism
  3. ValidationAspects
  4. EnterpriseLibrary Вход
  5. EnterpriseLibrary Обработка исключений
  6. EnterpriseLibrary Кэширование
  7. Caliburn

Все эти рамки значительно помогли с точки зрения усилий в области развития. Однако есть некоторые негативные аспекты:

  1. Тонны библиотек (15 из вышеприведенного списка).
  2. Уровень приложения (не общие сборки и новые сборки) должен ссылаться на многие базовые dll, которые могут сбивать с толку), и задействовано множество различных пространств имен.
  3. Развертывание данных тонких библиотек может стать проблематичным (иногда я использую ILMerge для облегчения этой и вышеупомянутых проблем, но давайте отложим это на время).
  4. Срок действия проекта с открытым исходным кодом - проекты с открытым исходным кодом приходят и уходят, поэтому, если какая-либо из них перестает активно поддерживаться, это может быть связано с наличием внутренних ошибок, требующих исправления или улучшения, которые мы хотим.
  5. Обфускация «как делать вещи». Мы не активно используем все части вышеуказанных структур. Фактически, некоторые из этих структур имеют перекрытие и обеспечивают избыточные компоненты и функциональность. С точки зрения развития это может сбить с толку. Мы хотим, чтобы последовательная реализация была простой и понятной в нашей базе кода. Наличие нескольких областей, которые делают одно и то же по-разному, может быть проблематичным в этом отношении. Это, наверное, одна из моих самых больших проблем.
  6. У вас большие проблемы, если эти фреймворки ссылаются на разные версии других сборок (т. Е. Внутренне ссылаются на Unity 1.1 и еще один Unity 2.0).

Альтернатива? Включите исходный код в общую dll для ваших проектов (например, MyProject.Common). Давайте пока отложим вопрос о соблюдении требований к лицензии.

Это имеет несколько негативных последствий также:

  1. Это не так легко использовать обновление, выпущенное компанией поставщиком фреймворки - вам необходимо обновить исходный код.
  2. Инкапсуляция функциональности - это легче разбить эту парадигму, когда исходный код находится в ваших руках.

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

Спасибо.

ответ

2

Для некоторых аспектов вашей проблемы это может быть актуально: http://en.wikipedia.org/wiki/DLL_hell#Running_Conflicting_DLLs_Simultaneously.

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

Что касается срока действия проекта с открытым исходным кодом, должно быть понятно, какие проекты являются здоровыми, а какие нет. Например, проект, который является частью фондов Apache или Eclipse, вероятно, здоров, тогда как некоторые случайные вещи на sourceforge, вероятно, нет. Как правило, вы можете вообще избежать этой проблемы, избегая проектов, которые не кажутся активными.

Для негативы копирования кода в ваш проект:

  1. Я знаю, что вы хотели поставить лицензию в сторону, но вы не можете на самом деле. Я не юрист, и вам следует проконсультироваться с одним из них для вашего проекта, если могут возникнуть проблемы, но если вы разрабатываете проприетарную систему, это может случайно стать GPL'ом.
  2. Это делает вашу среду разработки более загроможденной. Вам нужно беспокоиться о том, чтобы правильно скопировать код ompiles, компилируется с правильной версией и имеет правильные скрипты сборки. У вас также есть весь этот дополнительный код в вашей среде IDE, который занимает место.
  3. Как вы указали, это очень затрудняет обновление кода.
  4. Если вам приходится записывать ошибки с проектом с открытым исходным кодом, это становится сложнее сделать.
  5. Если вы не будете осторожны, младший разработчик, который не знает ничего лучше, может войти в код и начать с ним работать.

Есть, вероятно, больше причин не делать этого, но это несколько. Надеюсь, это поможет.

+0

Можете ли вы или кто-нибудь еще прокомментировать причины не просто включать исходный код для фреймворков с открытым исходным кодом в свой собственный исходный код? – Jeff

+0

ОК, добавлено несколько причин. Удачи! –