Пространство имен/структура решения
Прошу прощения за столь обобщенный вопрос, но это то, что может оказаться сложным для меня. Моя команда собирается начать большой проект, который, надеюсь, объединит все случайные единичные кодовые базы, которые развивались в течение многих лет. Учитывая, что этот проект будет охватывать стандартизацию логических сущностей по всей компании ("Клиент", "Сотрудник"), мелкие задачи, крупные задачи, которые управляют мелкими задачами, и коммунальные службы, я изо всех сил пытаюсь понять, как лучше структурировать пространства имен и структуру кода.
Хотя, наверное, я не даю вам достаточно конкретики, у вас есть какие-нибудь ресурсы или советы о том, как подойти к логическому разделению доменов? Если это поможет, большая часть этой функциональности будет раскрыта через веб-сервисы, а мы Microsoft магазин со всеми последними штуковинами и гаджетами.
- Я обсуждаю возможность создания одного массивного решения с подпроектами для облегчения ссылок, но не получится ли это слишком громоздким?
- Должен ли я обернуть функциональность унаследованного приложения или оставить ее полностью независимой от пространства имен (например, сделать класс
OurCRMProduct.Customerпротив общего классаCustomer)? - Должна ли каждая служба/проект иметь свои собственные
BALиDAL, или это должна быть совершенно отдельная сборка, на которую все ссылается?
У меня нет опыта организации таких масштабных проектов, только разовые, поэтому я ищу любые рекомендации.
Существует миллион способов снять шкуру с кошки. Однако самый простой всегда самый лучший. Какой способ самый простой для вас? Зависит от ваших требований. Но есть несколько общих правил, которым я следую.
Во-первых, максимально сократите общее количество проектов. Когда вы компилируете по двадцать раз в день, лишняя минута только увеличивает время.
Если ваше приложение рассчитано на расширяемость, подумайте о разделении сборок по принципу "дизайн против реализации". Разместите свои интерфейсы и базовые классы в общедоступной сборке. Создайте сборку для реализаций этих классов в вашей компании.
Для больших приложений разделите логику пользовательского интерфейса и бизнес-логику.
УПРОЩАЙТЕ свое решение. Если оно выглядит слишком сложным, то, скорее всего, так оно и есть. Объединяйте, сокращайте.
Мой совет, начав подобное обязательство, не состоит в том, чтобы мучиться над пространствами имен..
Только начните развиваться с несколькими важными свободными рекомендациями, потому что однако Вы начинаете, Ваш проект органический, и Вы будете заканчивать тем, что реорганизовывали пространства имен и классы со временем.
Don' t напрасно тратят время, говоря слишком много о Вашем проекте. Просто сделайте это.
Недавно я столкнулся с тем же самым на работе. Много специального кода, который нужно было структурировать и упорядочить.
Поначалу это очень трудно, потому что их так много. Думаю, лучший совет, который я могу дать, - это вложить в это время в пятницу днем, в течение пары недель я просто выбирал приложение/кусок кода, изучал то, что там было, думал о том, что мы можем сделать общим, копировал это, помещал в новую библиотеку, куда считал нужным. Как только я переносил весь код приложения, я работал над рефакторингом приложения, чтобы оно работало на основе общего фреймворка. Это иногда вызывало проблемы, которые нужно было исправлять, но пока вы тщательно все делаете, это не должно быть слишком большой проблемой.
Кусочек за кусочком - это единственный способ сделать это.
Что касается структуры, я попытался подражать разметке имен MS, поскольку в основном она довольно логична (например, Company.Data , Company.Web , Company.Web.UI и так далее.
Одним из основных преимуществ, вероятно, является количество удаленного дублирования кода. Да, в приложениях потребовался небольшой рефакторинг, но кодовая база стала гораздо более компактной и во многих отношениях "умнее".
Еще одна вещь, которую я заметил, это то, что у меня часто возникали проблемы при попытке понять, куда поместить материал (с точки зрения пространства имен), поскольку я не был уверен, к чему он относится. Это действительно беспокоило меня, я воспринимал это как неприятный запах. После реорганизации все теперь гораздо лучше ложится на свои места. И с (теперь очень небольшим количеством) кода, специфичного для приложений, они помещаются в Company.Applications.ApplicationName Это помогает мне действительно больше думать о бизнес-объектах, поскольку я не хочу слишком многого в этом пространстве имен, поэтому я придумываю более гибкие проекты.
Извините за длинный пост. Он немного бессвязный!
Мы называем собрания в.NET следующим путем Компанией. Проект. XXXX.YYYY, где XXXX Проект и YYYYY, является подпроектом, например:
- LCP.AdmCom. Распространенный
- LCP.AdmCom. BusinessObjects
- LCP.AdmCom. Распространенный. Dal
Мы берем это от книжного требования Руководство по проектированию Структуры Кшиштофом Цвалиной (Автор), Брэд Абрамс (Автор)
Для крупных проектов подход, который мне нравится проявлять, должен иметь одно пространство имен Области для моих деловых объектов и затем использовать Объекты Передачи данных (DTO' s) в моих слоях, где хранение и поиск делового объекта необходимы. DTO - простой объект это doesn' t содержат любую бизнес-логику.
Вот связь, которая объясняет DTO:
Большие решения с большим количеством проектов могут компилироваться довольно медленно, но ими легче управлять вместе.
Я часто располагаю сборки Unit test в том же решении, что и те, которые они тестируют, так как вы обычно вносите изменения в них вместе.
