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

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

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

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

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

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

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

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

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

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

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

Часть за частью, это единственный способ сделать это.

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

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

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

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

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

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

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

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

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

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

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

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