Пространство имен / структура решения - PullRequest
10 голосов
/ 15 августа 2008

Я прошу прощения за то, что задал такой обобщенный вопрос, но это может оказаться сложным для меня. Моя команда собирается начать большой проект, который, как мы надеемся, объединит все случайные одноразовые кодовые базы, которые развивались в течение многих лет. Учитывая, что этот проект будет охватывать стандартизацию логических объектов в компании («Заказчик», «Сотрудник»), небольшие задачи, большие задачи, которые управляют небольшими задачами, и коммунальные услуги, я изо всех сил пытаюсь найти лучший способ структурировать пространства имен и структура кода.

Хотя я полагаю, что я не даю вам достаточно подробностей, У вас есть какие-либо ресурсы или советы о том, как логически разделить ваши домены ? В случае, если это поможет, большая часть этой функциональности будет раскрыта через веб-сервисы, и мы - Microsoft магазин со всеми последними гизмо и гаджетами.

  • Я обсуждаю одно масштабное решение с подпроектами, чтобы упростить ссылки, но будет ли это слишком громоздким?
  • Должен ли я обернуть устаревшие функциональные возможности приложения или оставить это полностью независимым в пространстве имен (например, сделать класс OurCRMProduct.Customer вместо общего класса Customer)?
  • Должен ли каждый сервис / проект иметь свои собственные BAL и DAL, или это должна быть совершенно отдельная сборка, на которую все ссылаются?

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

Ответы [ 6 ]

12 голосов
/ 15 августа 2008

Есть миллион способов убрать кошку. Однако самый простой - всегда лучший. Какой способ для вас самый простой? Зависит от ваших требований. Но есть некоторые общие правила, которым я следую.

Во-первых, максимально сократите общее количество проектов. Когда вы компилируете двадцать раз в день, эта дополнительная минута складывается.

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

В больших приложениях разделите логику пользовательского интерфейса и бизнес-логику.

Упростите ваше решение. Если это выглядит слишком сложным, это, вероятно, так. Объединить, уменьшить.

7 голосов
/ 15 августа 2008

Мой совет, взявшись за подобное начинание, не мучиться из-за пространств имен ..

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

Не тратьте время на разговоры о вашем проекте. Просто сделай это.

4 голосов
/ 15 августа 2008

Мы называем сборки в .NET следующим образом Company.Project.XXXX.YYYY, где XXXX - это проект, а YYYYY - это подпроект, например:

  • LCP.AdmCom.Common
  • LCP.AdmCom.BusinessObjects
  • LCP.AdmCom.Common.Dal

Мы взяли это из книжного звонка Руководство по проектированию рамок Кшиштофа Квалина (Автор), Брэд Абрамс (Автор)

4 голосов
/ 15 августа 2008

Я недавно испытал то же самое на работе. Много специального кода, который нужно было структурировать и организовать.

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

Кусочек за штукой, это единственный способ сделать это.

С точки зрения структуры я пытался имитировать пространство имен MS, поскольку по большей части оно довольно логично (например, Company.Data , Company.Web , Company.Web.UI и т. Д.

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

Еще одна вещь, которую я заметил, это то, что у меня часто бывают проблемы с попыткой выяснить , куда поместить материал (в терминах пространства имен), так как я не был уверен, к чему он принадлежит. Теперь это действительно касалось меня, я считал его таким неприятным запахом. С тех пор как все перестроилось, теперь все гораздо приятнее. А с (в настоящее время очень небольшим количеством) кода, специфичного для приложения, они помещаются в Company.Applications.ApplicationName Это помогает мне действительно больше думать о бизнес-объектах, так как я не хочу слишком много в этом пространстве имен, поэтому я придумываю более гибкие конструкции.

Извините за длинный пост .. Это вроде бессвязно!

3 голосов
/ 15 августа 2008

В крупных проектах я предпочитаю использовать одно пространство имен домена для моих бизнес-объектов, а затем использовать объекты передачи данных (DTO) в моих слоях, где требуется хранение и извлечение бизнес-объекта. DTO - это простой объект, который не содержит никакой бизнес-логики.

Вот ссылка, объясняющая DTO:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

0 голосов
/ 15 августа 2008

Большие решения с большим количеством проектов могут быть довольно медленными для компиляции, но ими легче управлять вместе.

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

...