куда девается модель?

Question

У меня есть решение VS, со следующими проектами.

-gui
-DataAccess
-BusinessLogic
-БизнесОбъекты

но где должен находиться основной класс модели? Обычно это кэш набора объектов, которые являются результатами уровня доступа к данным и графического интерфейса пользователя, использующего виртуальные сетки для просмотра данных внутри модели. Вопрос будет таким же, используя MVC или MVP

мысли

Answer 1

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

Еще один вариант разделения функциональности на отдельные развертываемые блоки (сборки) состоит в том, чтобы группы могли функционировать более независимо. Раздельные проекты, основанные на частоте развертывания и групповой автономии.

Наконец, я видел несколько проектов, в которых объекты модели вызывались удаленно (например, с удаленным взаимодействием .NET) и обслуживались на сервере приложений, отдельном от веб-сервера. Я действительно не рекомендую такой подход, но это вариант.

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

Тем не менее, 99% времени у меня есть эти проекты:

• UI
• Основной
• Настойчивость
• Тесты

Но вы все равно должны учитывать потребности вашего проекта.

Answer 2

Я склонен иметь

• Justice.Project.Core & mdash; модель домена POCO & mdash; т.е. бизнес-объекты)
• Justice.Project.Data & mdash; Сопоставления NHibernate и т. Д., Где находится схема постоянства
• Justice.Project.Services & mdash; хранилища, а также бизнес-логика, которая не может быть легко вписана в бизнес-объекты
• Justice.Project.(Web|UI)

Модель - это & ndash; или должно быть & ndash; бизнес-объекты.

Answer 3

Я согласен с тем, что модельные объекты входят в ПОКО. так скажем, у меня есть заказ объект. Мой вопрос где у меня класс, который хранит коллекцию заказы ??

Это зависит от вашего бизнеса. Скорее всего, у вас будет коллекция заказов в нескольких разных местах ...

На вашем объекте клиента у каждого клиента должна быть коллекция заказов, так что у вас там будет один.

Если у вас есть отделы, у каждого отдела должна быть коллекция заказов, которые они создали.

Если у вас есть склады, на каждом складе может быть коллекция заказов, за которые они несут ответственность.

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

IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();

То же самое может относиться к вашим заказам.

Я бы рекомендовал проверить эту книгу DDD: http://www.amazon.com/gp/product/0321268202/ref=s9k2a_c1_at1-rfc_p-3237_p?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1BWAPTN787CTZXJDV5BA&pf_rd_t=101&pf_rd_p=463383351&pf_rd_i=507846

Answer 4

Мои решения имеют 3 (не тестовых) проекта

1. пользовательский интерфейс - очевидный
2. Core - все доменные объекты и бизнес-логика
3. Доступ к данным - Шаблон репозитория для заполнения / сохранения объектов модели