My<cod/>.net
Структура пространства имен / решения
Я прошу прощения за то, что задаю такой обобщенный вопрос, но это то, что может оказаться сложным для меня. Моя команда собирается приступить к большому проекту, который, как мы надеемся, объединит все случайные одноразовые кодовые базы, которые развивались на протяжении многих лет. Учитывая, что этот проект будет охватывать стандартизацию логических сущностей по всей компании ("Customer", "Employee"), малые задачи, большие задачи, которые управляют малыми задачами, и коммунальные службы, я изо всех сил пытаюсь найти лучший способ структурировать пространства имен и структуру кода.
Хотя я думаю, что не даю вам достаточно подробностей, чтобы продолжать, у вас есть какие-либо ресурсы или советы о том, как подходить к разделению ваших доменов логически ? Если это поможет, большая часть этой функциональности будет раскрыта через веб-службы, и мы-Магазин Microsoft со всеми последними вещами и гаджетами.
- Я обсуждаю одно крупное решение с подпроектами, чтобы сделать ссылки проще, но не будет ли это слишком громоздким?
- Следует ли мне свернуть устаревшую функциональность приложения или оставить ее полностью агностичной в пространстве имен (например, сделать класс
OurCRMProduct.Customerпо сравнению с общим классомCustomer)? - Должен ли каждый сервис / проект иметь свои собственные
BALиDAL, или это должен быть совершенно отдельный assembly, на который ссылается все?
У меня нет опыта в организации таких далеко идущих проектов, только разовые, поэтому я ищу любые рекомендации, которые могу получить.
Есть миллион способов освежевать кошку. Однако самый простой из них всегда является лучшим. Какой путь для вас самый простой? Зависит от ваших требований. Но есть несколько общих правил, которым я следую.
Во-первых, максимально сократить общее количество проектов. Когда вы делаете компиляцию двадцать раз в день, эта дополнительная минута складывается.
Если ваше приложение предназначено для расширяемости, рассмотрите возможность разделения сборок по направлениям проектирования и реализации. Разместите свои интерфейсы и базовые классы в общедоступном assembly. Создайте assembly для реализации этих классов в вашей компании.
Для больших приложений храните логику UI и бизнес-логику отдельно.
SIMPLIFY ваше решение. Если это выглядит слишком сложным, то, вероятно, так оно и есть. Объединить, уменьшить.
Мой совет, взявшись за подобное предприятие, не мучиться из-за пространства имен..
Просто начните разработку с нескольких важных свободных рекомендаций, потому что, как бы вы ни начинали, ваш проект органичен, и вы закончите реорганизацией пространств имен и классов с течением времени.
Не тратьте слишком много времени на разговоры о своем проекте. Просто сделай это.
Недавно я испытал то же самое на работе. Много специального кода, который нужно было структурировать и организовать.
Это действительно трудно сначала, так как есть так много. Я думаю, что лучший совет, который я мог бы дать , - это просто вложить время в него на ветру в пятницу днем, в течение нескольких недель я бы просто выбрал приложение/кусок кода, изучил, что там было, подумал о том, что мы могли бы сделать общим, скопировать его, поместить его в новую библиотеку, где я думал, что он должен быть. После того, как весь код в приложении был перенесен, я бы работал над рефакторингом приложения для работы с общей платформой.. Это иногда вызывало проблемы, которые необходимо было исправить, но до тех пор, пока ваша тщательность не будет слишком большой проблемой.
Кусочек за кусочком, это единственный способ сделать это.
С точки зрения структуры, я попытался как бы имитировать пространство имен MS, поскольку по большей части оно довольно логично (например, Company.Data , Company.Web , Company.Web.UI и так далее.
Одно из главных преимуществ, вероятно, заключается в количестве удаляемого кода dupe. Да, в приложениях требовался небольшой рефакторинг, но кодовая база намного меньше, и во многих отношениях "smarter".
Еще одна вещь, которую я заметил, - это то, что у меня часто возникали проблемы, пытаясь понять, куда поместить материал (с точки зрения пространства имен), поскольку я не был уверен, к чему он принадлежит. Теперь это действительно беспокоило меня, я рассматривал это как такой плохой запах. С момента реорганизации все теперь попадает в космос гораздо более красиво. И с помощью (теперь уже очень небольшого количества) специального кода приложения они помещаются в Company.Applications.ApplicationName это помогает мне действительно думать о бизнес-объектах намного больше, так как я не хочу слишком много в этом пространстве имен, поэтому я придумываю более гибкие конструкции.
Извините за длинный пост.. Это какая-то бессвязность!
Мы называем сборки в .NET следующим образом Company.Project.XXXX.YYYY, где XXXX-это проект, а YYYYY-подпроект, например:
- LCP.AdmCom.Common
- LCP.AdmCom.BusinessObjects
- LCP.AdmCom.Common.Dal
Мы берем это из книги call Framework Design Guidelines by Krzysztof Cwalina( автор), Брэд Абрамс (автор)
Для больших проектов мне нравится подход, который заключается в том, чтобы иметь одно доменное пространство имен для моих бизнес-объектов, а затем использовать объекты передачи данных (DTO) в моих слоях, где требуется хранение и извлечение бизнес-объекта. DTO-это простой объект, который не содержит никакой бизнес-логики.
Вот ссылка, которая объясняет a DTO:
http://martinfowler.com/eaaCatalog/dataTransferObject.html