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

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

Вот что есть в нашей библиотеке:

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

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

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

Это ломается, потому что:

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

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

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

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

Спасибо!

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


.net c# asp.net-mvc-3 class-library shared-libraries
person IronicMuffin    schedule 16.01.2012    source источник
comment
Посмотрите здесь stackoverflow.com /вопросы/1235253/. Вы можете добавить свои собственные материалы для поиска сборок. Слишком много в одной dll, на мой взгляд, тоже....   -  person Tony Hopkinson    schedule 17.01.2012
comment
Я собираюсь поместить это как комментарий, а не ответ, потому что я действительно не рекомендую это, но я предполагаю (при условии, что у вас есть соответствующий доступ к вашему серверу(ам)) вы могли бы поставить соединения в вашей папке bin для общих библиотек DLL в одном центральном месте. Затем вы просто помещаете новую DLL в одно центральное место, на которое указывают все соединения. Однако я не уверен, что мне вообще нравится эта идея.   -  person rejj    schedule 17.01.2012
comment
Это звучит грубо, и соединения не обязательно используются очень часто, верно? Вы предлагаете это, чтобы обмануть .net, заставив его думать, что все dll находятся в одном каталоге?   -  person IronicMuffin    schedule 17.01.2012

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

person Bill Martin    schedule 16.01.2012
comment
Цель создания одного места заключалась в том, чтобы мы могли скинуть один файл и все получили обновление. Я подумал, что это скорее ад DLL, когда эти 3 проекта имеют одну версию, эти 2 — самую последнюю, а эти 5 — еще более старую версию и т. д. - person IronicMuffin; 17.01.2012

arrow_upward
0
arrow_downward

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

person Tiny Montgomery    schedule 27.01.2014