Установка модели представления влечет за собой много вызовов уровня обслуживания, это правильно? - PullRequest
0 голосов
/ 27 января 2011

Моя архитектура такова: проект пользовательского интерфейса (MVC), подключенный к моему уровню доменных служб (бизнес-правила и т. Д.), Подключенный к уровню репо.

При настройке моделей представлений я, кажется, много раз обращаюсь к сервисному слою базы данных 9via) для настройки модели представления (т. Е. Представления) в контроллере, это правильная вещь ...

например. У меня есть клиент, они могут стать головным офисом (флажок), если они становятся / или являются головным офисом, у них есть возможность добавить много разных клиентов. Это конкретное представление будет содержать: детали клиента, доступные клиенты для добавления и текущие клиенты, которые являются частью головного офиса ...

Мне кажется, что я должен проверять все на уровне доменного сервиса и возвращать контроллеру то, что он может видеть, т. Е. Если это HeadOffice, имеет x количество клиентов, которые он может добавить ???

1 Ответ

0 голосов
/ 31 января 2011

Я не совсем уверен в вопросе, но вот мое понимание вопроса ...

1) Запись клиента будет содержать определенную информацию во всех случаях, и вы можете вернуть клиентазапись за один вызов

2) Если запись клиента имеет IsHeadOffice == true, вы можете дополнительно выбрать загрузку списка записей клиента IEnumerable, которые «принадлежат» «клиенту главного офиса»

На самом деле я не вижу проблемы в совершении двух вызовов: одного - для метода «получить клиента», а другого - для метода «получить клиентов для пользователя из центрального офиса».

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

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

...