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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

По частям, это единственный способ сделать это.

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

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

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

Извините, за длинную статью..Это какой-то бред!

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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