Что такое простой в обслуживании способ поделиться общей библиотекой классов .net со многими корпоративными веб-приложениями asp.net mvc 3?

Question

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

Вот что мы имеем в нашей библиотеке:

• Базовые классы для контроллеров иуслуги
• Бизнес-объекты (магазины, отделы и т. д.)
• Общие частичные представления (логин, ошибка и т. д.)
• Базовый класс для HttpApplication
• Общие общиекод (прочитайте INI-файл, создайте базу данных и т. д.)

Единственное требование, которое доставляет мне неприятности, заключается в следующем:

• Живет в одном месте насервер.(т. е. скопировать local = false)

Это прерывается, потому что:

• DLL-библиотека, содержащая класс HttpApplication, должна находиться в том же каталоге, что и DLL-файлы веб-приложений для запуска.Я не нашел способ обойти это.Я в порядке с дублированием этого кода в каждом приложении, но лучше не будет.
• Общие представления не любят работать, если я использую Assembly.LoadFrom () для загрузки библиотеки DLL из общего расположения.(Я использовал этот метод для предварительной компиляции моих представлений)
• Любые ярлыки пространства имен в web.config прерываются во время выполнения с ошибками компиляции, потому что web.config анализируется перед загрузкой сборки.

Мой вопрос к вам, ребята, как вы обрабатываете свой общий код в аналогичной среде?

GAC, похоже, доставляет больше хлопот, чем стоит, и мы хотим, чтобы все наши приложения использовали один и тот же код, а не имели несколько приложений в нескольких версиях и должны поддерживать все это.Есть ли в этом отношении шаблоны проектирования / лучшие практики, которыми мы можем руководствоваться в этом отношении?

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

Спасибо!

Редактировать: Я предполагаю, что следующий вопрос заключается в том, должны ли мы даже иметь каталог с общими dll на сервере, или они должны быть только развернутыкак проекты развертываются / обновляются?

Answer 1

Во-первых, вы захотите выделить то, что вы пытаетесь достичь. Не создавайте 1 библиотеку, которая делает все, иначе у вас будет Big Ball of Mud . Не бойтесь создавать несколько поддерживаемых библиотек, чтобы достичь того, что вам нужно. Есть ли конкретная причина, по которой его нужно хранить в одном месте?

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

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

Я предпочитаю копировать библиотечные библиотеки локально. Вы никогда не знаете, когда вам нужно будет внести изменения в библиотеку, но вы не хотите, чтобы все ваши проекты перестали компилироваться. Когда вы будете готовы реализовать новую версию библиотеки, скопируйте dll-файл и перекомпилируйте.

Answer 2

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