Совет по архитектуре приложений

Я изучал различные шаблоны для создания многоуровневого приложения MVC, и мне нужен небольшой совет. В настоящее время у меня есть следующее:

1) Модель домена POCO, без бизнес-логики вообще, поэтому в основном анемичная модель домена.
2) EntityFramework с уровнем репозитория, который возвращает объекты домена.
3) Уровень обслуживания, теперь я не уверен, что это уровень службы приложения или уровень службы домена, но в основном это API в отношении модели домена. Вся бизнес-логика находится на этом уровне и гарантирует, что объекты домена действительны, а затем передает их в репозитории для сохранения через EF обратно в БД.
4) Приложение ASP.NET MVC, это приложение обращается к уровень обслуживания, чтобы получить необходимые объекты.

Мне нравится, как это работает, поскольку он обеспечивает единую точку взаимодействия с моделью предметной области, но, как мне кажется, мне нужен промежуточный слой между уровнем сервиса и приложением mvc. Ответственность за этот уровень будет заключаться в преобразовании объектов домена в модели представления и из них, с которыми контроллер может взаимодействовать, чтобы получить точные данные, необходимые представлению, и предоставить заполненные объекты домена обратно на уровень службы. Будет ли это уровень службы приложения, а упомянутый выше уровень службы - это уровень службы домена?

Я использую AutoMapper для получения объектов домена в моделях представления, но я не уверен в стандарте их возврата в объект домена.

Любые советы или идеи были бы замечательными.


person Sam    schedule 07.08.2012    source источник
comment
В этом описании довольно много модных словечек и мало деталей. Однако даже если вы конкретизируете это, это не тот вопрос, который подходит для SO. Что касается дизайна, то он слишком открытый и субъективный.   -  person cHao    schedule 07.08.2012
comment
+1 Несмотря на то, что я не думаю, что этот вопрос строго соответствует руководящим принципам SO относительно того, каким должен быть хороший вопрос (например, очень широким, без образца кода), я все равно голосую за него. Я борюсь с этими вопросами, и я надеюсь, что вы получите хорошие ответы.   -  person Dan A.    schedule 07.08.2012


Ответы (1)


Хотя теоретически классы вашего уровня домена (особенно если вы используете POCO) отлично подходят для использования в контроллерах и представлениях, на практике всегда есть эти угловые случаи и различия. Обычно объекты, с которыми имеют дело контроллеры и представления, являются упрощениями POCO вашей модели домена или различными агрегациями ваших POCO, отличными от того, что предоставляет / понимает ваш уровень службы приложений.

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

Например, если у вас есть User класс уровня домена и UserModel модель просмотра, я бы рекомендовал создать User ToUser() метод экземпляра и UserModel UserModel.FromUser(User user) статический метод для преобразования. Вы также можете смешивать и сопоставлять другие модели представления, чтобы иметь возможность создавать объекты домена.

person Dmitry Frenkel    schedule 10.04.2013