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

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

So:

  1. Контроллер -> Сервис -> getUserById() или:

  2. Контроллер -> ServiceManager -> getUserService() -> getUserById()

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

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

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


service model-view-controller layer
person Decent Dabbler    schedule 29.08.2009    source источник

Ответы (3)


arrow_upward
4
arrow_downward

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

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

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

person krosenvold    schedule 29.08.2009
comment
Кросенволд спасибо за ответ. По поводу вашего ответа: А) Понял и согласился Б) Я понимаю, что вы говорите об избыточной абстракции. Но, как я сказал Джоэлу: мне трудно понять, как IoC будет реализован в среде MVC. Где бы это произошло? В контроллере? Как это предлагает дополнительную ценность? Я не думаю, что слишком хорошо понимаю принцип IoC, чтобы понять его преимущества. Или мы говорим о настройке его и в бутстрапе? Если вы хотите уточнить (возможно, с кратким примером), я буду очень признателен. Спасибо. - person Decent Dabbler; 30.08.2009
comment
Ключевая концепция внедрения зависимостей заключается в том, что для того, чтобы быть эффективным, он должен использоваться в большинстве мест. Обычно вы подключаете контейнер IoC на очень низком уровне инфраструктуры, и он просто проникает повсюду. - person krosenvold; 30.08.2009

arrow_upward
3
arrow_downward

Использование «фасада» - это один из способов:

"Фасад — это объект, предоставляющий упрощенный интерфейс для большей части кода"

person Dexygen    schedule 29.08.2009

arrow_upward
2
arrow_downward

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

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

person Joel Martinez    schedule 29.08.2009
comment
Джоэл, спасибо за ваш ответ. Я согласен с вашим возражением против того, чтобы называть его Сервисом. Я только что понял это, но на самом деле сам немного нахмурился. Но концепция слоя мне понравилась. В данный момент я пытаюсь понять всю концепцию внедрения зависимостей, но мне не совсем понятно, как это работает. Не могли бы вы привести краткий пример того, как это будет работать в среде MVC? Я имею в виду, куда бы вы вводили, что в какой объект, если, например, речь идет о получении объектов пользователя? Мне трудно понять эту концепцию. Заранее спасибо. - person Decent Dabbler; 30.08.2009
comment
поверьте мне, когда я говорю, что понимаю, когда вы говорите, что пытаетесь понять ioc. мне потребовалось немного времени, чтобы понять, когда и где его использовать :-) это поле для комментариев слишком маленькое, чтобы по-настоящему разобраться в нем, но я бы посоветовал проверить библиотеку ninject (ninject.org). их учебные пособия проходят шаг за шагом и начинают знакомить с концепциями. Подводя итог, все дело в отделении API от конкретной реализации. ваш код в проекте mvc должен работать с вашим API, а не с вашими конкретными реализациями... таким образом, вы можете изменить их позже при модульном тестировании - person Joel Martinez; 30.08.2009
comment
По словам Мартина Фаулера, сервисный уровень определяет границу приложения с уровнем сервисов, который устанавливает набор доступных операций. В линейке бизнес-приложений эти операции обычно являются CRUD, но не всегда. Поэтому я не думаю, что сервисный уровень = репозиторий. Как настоящий сервисный слой (который мне нравится) вписывается в MVC, для меня до сих пор остается загадкой. Я чувствую, что M в MVC следует заменить на S. Разве контроллеры не образуют сервисный уровень, о котором я говорю? Думаю, так делает большинство людей. Но должны ли контроллеры определять границы приложений? Я в замешательстве... - person ; 16.02.2010
comment
Границ может быть несколько. Я думаю, что это то, где вы запутались. MVC должен заниматься только тем, что нужно делать этому конкретному приложению. Таким образом, можно было увидеть архитектуру, в которой модель взаимодействует с сервисным уровнем (который, как вы упомянули, может быть CRUD). - person Joel Martinez; 16.02.2010