Код организации Connundrum: веб-проект с несколькими вспомогательными библиотеками DLL?

Question

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

Предполагая, что нет правильного ответа, это то, что я сейчас есть для организации кода:

MyProjectWeb

Это мой веб-сайт. Я ссылаюсь здесь на мои библиотеки классов.

MyProject.DLL

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

MyProject.IO.DLL

Это группа из примерно 20 файлов, которые обрабатывают загрузку файлов и скачать (пока).

MyProject.Utilities.DLL

Все мои общие классы и методы объединены в один в общем расходная DLL. Каждый класс следует соглашению "XHelper" такие как "SqlHelper, AuthHelper, SerializationHelper и т. д. ...

MyProject.Web.DLL

Я использую эту DLL в качестве основного клиентского интерфейса. Сейчас большинство файлов классов здесь:

1) свойства (например, школа, местоположение, учетная запись, сообщения) 2) авторизация (например, пользовательское членство, пользовательская роль, и поставщики пользовательских профилей)

Мой вопрос прост - кажется ли это логичным?

Кроме того, как избежать перекрестной ссылки на библиотеки DLL из одного библиотека проекта к следующему? Например, MyProject.Web.DLL использует код из MyProject.Utilities.DLL и MyProject.Utilities.DLL использует код из MyProject.DLL. Решается ли это, нажав на свойства и выбрав «Зависимости»? Я попробовал это, но все еще не получаю доступ к пространствам имен сборка я выбрал. Должен ли я ссылаться на каждый Мне нужна сборка для каждой библиотеки классов?

Отзывы приветствуются и спасибо за ваше терпение.

Answer 1

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

В общем, вещи должны быть разбиты по концептуальным границам, а не по техническим. MyProject.IO.DLL - пример использования этого принципа в вашем текущем проекте. Все вещи ввода / вывода логически идут вместе, поэтому они заканчиваются в одном двоичном файле. Имеет смысл.

Разбить вещи на пространства имен по их техническому типу - enum, class и т. Д. - будет немного сложнее.

Проблема зависимостей та же, что и у вас, если разбить один класс на несколько, и она решается с использованием той же техники: инверсия зависимости. Там, где две вещи, по-видимому, должны зависеть друг от друга, добавьте посредническую вещь, которая представляет собой контракт между первыми двумя. Это могут быть абстракции, константы, посредники и т. Д. ... все, что вам нужно, чтобы сделать так, чтобы вместо вещи A, зависящей от вещи B, и вещи B, зависящей от вещи A, у вас были вещи A и B, зависящие от вещи C.