Пространство имен / структура решения

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

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

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

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

15.08.2008 13:30:42
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

12
15.08.2008 13:39:01

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

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

Шаг за шагом это единственный способ сделать это.

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

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

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

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

4
15.08.2008 13:39:06

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

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

0
15.08.2008 13:40:31

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

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

Мы взяли это из книги « Принципы разработки рамок» Кшиштофа Квалины (Автор), Брэда Абрамса (Автор)

4
15.08.2008 14:00:40

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

Вот ссылка, которая объясняет DTO:

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

3
15.08.2008 13:46:10

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

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

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

7
15.08.2008 14:01:08