Архитектуры решений, как правило, в значительной степени не зависят от используемой вами архитектуры пользовательского интерфейса, хотя у вас может быть дополнительное разделение , если вы планируете иметь несколько приложений пользовательского интерфейса (большинство проектов этого не делают).
Я склонен начинать с шаблона, подобного следующему:
Acme.Sales или Acme.Sales.Core - внутренний домен / бизнес-логика
Acme.Sales.Entities - объекты данных, используемые для постоянных слоев.Сущности имеют структуру классов, аналогичную базовой (доменной) модели, но, как правило, имеют более тонкую логику, дополнительные свойства, такие как Id, двусторонние отношения (в отличие от односторонних отношений в модели домена) и virtualчлены для ORM, чтобы иметь возможность переопределить.Эта сборка также обычно включает в себя abstract репозитории для операций CRUD над объектами.
Acme.Sales.Entities.Impl, где Impl - это что-то вроде LinqToSql или NHibernate -это пространство имен определяет одну возможную реализацию для фактического сохранения Entities. Конкретные реализации абстрактных репозиториев находятся здесь.
Acme.Sales.UI содержит общие классы, относящиеся к любому пользовательскому интерфейсу - может быть графический интерфейс MVPили даже CLI.Как и в случае Entities, они аналогичны классам Core, но, как правило, имеют специфичную для представления логику и атрибуты, такие как проверка и форматирование (что чаще всего сегодня выполняется через DataAnnotations).Обратите внимание, что базовая библиотека должна также проверять, но проверка пользовательского интерфейса, как правило, больше касается форматирования и очистки входных данных, чем бизнес-правил.Здесь заманчиво подражать структуре классов домена, но в целом вам будет проще, если вы будете придерживаться плоских классов в стиле DTO для вашей модели пользовательского интерфейса.
Acme.Sales.UI.Services содержитабстрактные или конкретные «сервисные» типы, предназначенные для взаимодействия как с пользовательским интерфейсом , так и со слоями домена / персистентности.Таким образом, этот проект принимает зависимости от Acme.Sales (домен), Acme.Sales.Entities (абстрактные репозитории), а также Acme.Sales.UI и обрабатывает все операции сопоставления между этими различными слоями.
Acme.Sales.UI.Impl где Impl здесь что-то вроде Mvp, Mvc, Mvvm и так далее.Вы можете удалить UI из этого пространства имен, если хотите, поскольку реализация подразумевает, что это такое.Обычно это зависит от проекта UI, но добавляет те вещи, которые характерны для конкретной модели пользовательского интерфейса;контроллеры, презентаторы, view-модели и т. д. Это ваше реальное «приложение».Это также место, где вы обычно выбираете контейнер IoC (AutoFac, Ninject, Spring.NET, Castle, Unity) и подключаете все конкретные реализации к абстрактным типам.
в рамках проекта приложенияВы хотите разделить логические понятия на разные подпространства / папки.Например, поместите ваши докладчики в Presenters и просмотры в Views - довольно просто - и создайте подкаталоги в каждом из них, если вы начнете получать действительно огромное количество экранов (например, Views.Billing и Views.Shipping).Также можно создавать здесь каталоги / пространства имен верхнего уровня Area и помещать отдельные Presenters, Views и т. Д. В каждую из этих областей - этот подход в настоящее время используется в ASP.NET MVC.
Вы не должны разделять Presenters и Views на разные проекты.Будьте уверены, что представления, которые вы создали для MVP, будут совершенно бесполезны для MVC или MVVM, и наоборот.Единственная часть приложения, управляемого моделями, которая действительно имеет шанс на повторное использование, - это сама модель.
Обратите внимание, что это всего лишь базовая архитектура для приложения с единой базой данных и относительно простой доменной логикой.Он не включает в себя какие-либо высокоуровневые внутренние конструкции, такие как интеграция приложений (например, веб-сервисы), обработка событий (pub / sub), пакетная обработка, CQS, специальные отчеты и т. Д. И т. Д.Они, как правило, довольно распространены в более масштабных бизнес-приложениях, но если вы только начинаете работу над новым приложением для создания закладок в социальных сетях, вам не понадобится ничего сложного.
Также обратите внимание: это все при условии, что вы планируете, по крайней мере, проект среднего размера - скажем, тот, над которым вы и / или ваша команда будете работать в течение 6 месяцев или более. Если вы планируете сделать это за 1 месяц или менее, то, пожалуйста, не тратьте время на архитектуру решений. Вполне нормально просто объединить все это в один проект и повторно использовать одни и те же классы для домена, сущностей, и UI - , пока проект достаточно мал, чтобы его можно было легко понять и поддерживать , Внимательно следите за сложностью и расходами на техническое обслуживание и рассмотрите возможность рефакторинга в вышеупомянутую структуру в течение более длительного периода времени, если проект начнет превращаться в комок грязи.