Реализация уровня обслуживания в архитектуре MVC

Как обычно реализовать уровень сервиса в архитектуре MVC? Это один объект, который обслуживает все запросы к базовым бизнес-объектам? Или это скорее объект, который обслуживает разные объекты службы, которые в свою очередь взаимодействуют с бизнес-объектами?Реализация уровня обслуживания в архитектуре MVC

Итак:

Controller -> Сервис -> getUserById(), или:
Controller -> ServiceManager -> getUserService() -> getUserById()

Кроме того, если последнее более подходит, настройте этот объект ServiceManager в бутстрапе? Другими словами, зарегистрируйте различные службы, которые вам понадобятся для вашего приложения, менеджеру службы в начальной загрузке?

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

Заранее спасибо.

источник

2009-08-29 Decent Dabbler

Как я прочитал этот вопрос, есть две вещи, которые должны быть Ответ:

A) Я бы предпочел разделить «Сервис» на «CustomerService» и «OrderService», другими словами, сгруппированные по понятиям домена.

B) Во-вторых, я использую инъекцию зависимостей, чтобы получить надлежащую услугу напрямую там, где она мне нужна, поэтому я в основном использую alt 1. Добавленная абстракция в альтернативе 2 не дает никакого дополнительного значения для меня, поскольку контейнер IoC делает важную роль.

источник

2009-08-29 19:03:12 krosenvold

Спасибо за ваш ответ krosenvold. Ответа на этот вопрос: A) Понял и согласился B) Я вижу, что вы говорите об избыточной абстракции. Но, как я прокомментировал Джоэлю: мне трудно понять, как IoC будет реализован в среде MVC. Где это будет? В контроллере? Как это предлагает дополнительную ценность? Я не думаю, что я хорошо понимаю принцип IoC, чтобы понять его преимущества. Или мы говорим о настройке в бутстрапе? Если вы хотите уточнить (возможно, с кратким примером), я очень это ценю. Благодарю. –

Ключевая концепция, чтобы понять, что инъекция зависимостей заключается в том, чтобы быть эффективной, она будет использоваться в * большинстве * местах. Обычно вы подключаете контейнер IoC на очень низком уровне инфраструктуры, и он просто пронизывает всюду. – krosenvold

Я лично предпочитаю # 2, и да, обычно это было бы сконфигурировано в бутстрапе, или зависимости будут разрешаться с использованием какого-то контейнера IoC, чтобы предоставить вам конкретные конкретные экземпляры.

Я также хотел бы прокомментировать, и да, я понимаю, что это, вероятно, более личное предпочтение. Попытайтесь избежать использования слоя «Сервис» для этих объектов. ссылайтесь на них как на репозитории или на что-то еще. если вы используете сервис, этот термин становится перегруженным ... потому что тогда разработчики похожи: «вы имеете в виду, как отдых или услуга wcf?». поверьте мне, мы сделали это с недавним проектом, и мы все время путаем себя, когда мы говорим о том, где делать изменения кода: -P

источник

2009-08-29 18:35:55

Joel, спасибо за ваш ответ. Я согласен с вашим возражением на то, чтобы назвать его Service. Я просто подхватил это, но на самом деле немного нахмурился. Но концепция слоя обратилась ко мне. В настоящий момент я пытаюсь понять всю концепцию инъекции зависимостей, но мне не совсем понятно, как это работает. Не могли бы вы привести краткий пример того, как это будет работать в среде MVC? Я имею в виду, где бы вы ввели то, что в объекте, если речь идет о возвращении объектов пользователя, например? Мне трудно понять эту концепцию. Заранее спасибо. –

доверяйте мне, когда я говорю, что я понимаю, когда вы говорите, что пытаетесь обернуть свою голову вокруг ioc. мне потребовалось немного времени, чтобы выяснить, когда/где его использовать :-) этот блок комментариев слишком мал, чтобы действительно в него попасть, но я бы предложил проверить библиотеку ninject (http://ninject.org/).их учебники проходят шаг за шагом и начинают вводить концепции. Подводя итог, все дело в том, чтобы отделить API от конкретной реализации. ваш код в проекте mvc должен работать против вашего API, а не ваших конкретных реализаций ... Таким образом, вы можете изменить их позже, когда модульное тестирование –

По словам Мартина Фаулера, сервисный уровень «определяет границу приложения со слоем услуг, который устанавливает набор доступных операций «В строке бизнес-приложений эти операции обычно являются CRUD, но не всегда. Поэтому я не думаю, что сервисный уровень = репозиторий. Как настоящий сервисный уровень (который мне нравится) подходит для MVC, по-прежнему остается загадкой для меня. Я чувствую, что M в MVC следует заменить на S. Если контроллеры не образуют слой обслуживания, о котором я говорю? Думаю, именно так это делают большинство людей. Но должны ли контроллеры определять границы приложения? Я смущен ... – 2010-02-16 15:43:02

Использование "фасад" является один путь:

"A facade is an object that provides a simplified interface to a larger body of code"

источник

2009-08-29 19:29:47

Реализация уровня обслуживания в архитектуре MVC

ответ

Смежные вопросы