3

Занимаюсь разработкой небольшого клиент-серверного приложения. Использую многослойную архитектуру. В настоящий момент закончил реализацию слоя доступа к данным, при разработке этого слоя использовал паттерн Репозиторий. Теперь у меня есть своеобразный шлюз (интерфейсный класс), при помощи которого слой бизнес-логики может получать все необходимые данные из базы данных.

Посоветуйте, какие паттерны следует использовать в слое бизнес-логики, чтобы затем реализовать, скажем, сервисный слой. Какие есть варианты?

Поправьте меня, если я чего-то недопонимаю, или вопрос задан некорректно. Спасибо.

Saidolim
  • 8,341
  • 4
  • 26
  • 48
klutch1991
  • 2,733
  • Вот тут архитектурная диаграмма смотрелась бы очень хорошо. – Nick Volynkin Dec 22 '15 at 09:46
  • а что в Вашем понимании сервисный слой?! – Bald Dec 22 '15 at 09:48
  • 4
    ну вопрос действительно несколько странноват. Вы же не думаете, что вам скажут примерно следующее: "о, чувак, раз ты написал слой данных, используя Репозиторий, то в бизнес-логике тебе непременно надо использовать абстрактные фабрики и фасады"? – DreamChild Dec 22 '15 at 09:50
  • @Bald56rus, например, WCF-сервис. В Microsoft Architecture Guide он находится между слоем бизнес-логики и слоем UI. – klutch1991 Dec 22 '15 at 09:50
  • @DreamChild, посоветуйте хотя бы в какую сторону смотреть, что читать. Да и то, что в DAL используется именно репозиторий, я думаю тут не при чём. Просто интересны названия паттернов, которые применимы в слое бизнес-логики. Я не имею в виду паттерны из каталога GOF. – klutch1991 Dec 22 '15 at 09:51
  • Вы не поняли: имел ввиду что делает сервисный слой в Вашем понимании, в моем понимании GUI работает со слоем который возвращает необходимый набор данный, если я правильно понял то у вас это слой бизнес логики?! – Bald Dec 22 '15 at 09:51
  • @Bald56rus, предоставляет набор методов для получения данных, которые будут использоваться в клиентском приложении. – klutch1991 Dec 22 '15 at 09:53
  • 2
    а что тогда делает слой с бизнес логикой? – Bald Dec 22 '15 at 09:54
  • @Bald56rus, по сути в моём понимании WCF (который и реализует сервисный слой) будет просто обёрткой над бизнес-слоем, при помощи которого я получу единый интерфейс, который позволит подключить как веб-клиенты, так и, скажем, клиенты WPF. – klutch1991 Dec 22 '15 at 09:57
  • в текущий момент у меня почти подобная архитектура организована: DAO, DAL, Services, GUI; в моем случае Services возвращает объекты в соответствии с логикой и именно методы(IEnumerable GetAll, Entity Get(int id)) из Services я дергаю в GUI. подумайте для чего вам этот лишний слой. – Bald Dec 22 '15 at 10:03
  • Мда. По всей видимости вы используете(сами того не зная) NLayer, только вот оправдано ли использование этого паттерна или нет - хз, из вашего вопроса не ясно. Добавьте в вопрос информацию о самой задаче, которую решает ваш проект, тогда можно будет поговорить о паттернах и прочем. – Мстислав Павлов Dec 22 '15 at 10:53
  • @klutch1991 WCF сервис там ради распределенного деплоя (он используется в физическом разделении на слои - N-Tier, а не в логическом N-Layer). У вас скорее всего стандартный NLayer, с сервисами, DTO, фасадом - он хорошо разрисован в Microsoft Archit1ecture Guide. WCF не нужен. Дергайте методы фасадов напрямую из Presentation. –  Dec 22 '15 at 11:06
  • 2
    @klutch1991 а в остальном - паттеры - это решения проблем. из стоит применять, когда вы видите конкретную проблему. Опишите проблему, с которой вы прямо сейчас столкнулись - и вам скажут как ее решать. А так - вопрос пока слишком общий. Можно только посоветовать 3-Layer + IoC + MVC (сейчас все так делают), причем даже самописный репозиторий, который вы прикрутили - под сомнением. Чем вас стандартная реализация Repository + Unit Of Work + Query Object + Mapper в виде контекста EF не устроила? –  Dec 22 '15 at 11:09

2 Answers2

8

В сервисном слое (слой бизнес-логики) можно использовать многие паттерны, как ОО паттерны, так и другие паттерны более узкого или широкого профиля. Все зависит от того, какие у вас задачи в этом слое встречаются. Невозможно дать общий готовый список шаблонов, вот, мол, используй вот это и будет тебе счастье. Не-воз-мож-но. И не нужно.

Забудьте на время о паттернах. Они не самоцель. Сперва делайте так, как вам кажется правильным. И в какой-то момент некоторые задачи покажутся знакомыми и уже их при желании можно решить, применив тот или иной паттерн.

Еще лучше, забудьте о паттернах на годик. И вернитесь к ним после того, как получите чуть больше опыта. Тогда, я уверяю вас, вы совершенно по-другому на них взглянете, и более того, даже поймете, что использовали некоторые из них, не осознавая этого. Проанализировав свой опыт, поймете, где могли бы применить тот или иной шаблон. Еще раз повторюсь, вы неправильно понимаете для чего нужны паттерны, если отталкиваетесь от них. Шаблоны -- не самоцель, а лишь средство. Это как спрашивать "я хочу построить дом, какой кирпич мне взять?". Вы не с того начинаете, строитель!

andreycha
  • 25,167
  • 4
  • 46
  • 82
  • "Невозможно дать общий готовый список" -- так и есть, но автор вопроса спросил "Какие есть варианты?". наверное надо в ответ добавить пару вариантов, которые покажут направление. иначе автор вопроса рискует и год, и два ходить по кругу, т.к. в книгах, статьях и т.д. очень много воды и неточностей. – Stack Dec 22 '15 at 13:14
  • 1
    @Stack вариантов есть штук так 30, а может и больше. У автора небольшая каша относительно целей и назначений паттернов, потому давать какой-то список просто нет смысла. Паттерны родились как систематизация накопленных знаний. И в их изучении и применении лучше идти по этому же пути -- сначала накопить опыт, а потом систематизировать его. – andreycha Dec 22 '15 at 13:41
  • "Паттерны родились как систематизация накопленных знаний" -- да, но я говорю не про все паттерны вообще, а про те, что реально используются, например, MVVM. – Stack Dec 22 '15 at 14:00
  • @Stack так и я говорю про те, что реально используются. Или, по-вашему, некоторые паттерны -- это исключельно фантазии авторов, не имеющие отношения к реальности? – andreycha Dec 23 '15 at 09:52
  • "так и я говорю про те, что реально используются. ... вариантов есть штук так 30" -- автор спрашивает про архитектурный шаблон, т.к. ему надо связать бизнес-логику и сервисы. в такой ситуации на практике используют не 30 штук каких-то паттернов. вы же наверное лучше меня знаете, что используется в приложениях .NET, вот я предложил обозначить направление, в котором автору надо 'копать'. я так понимаю, что вы с этим не согласны. т.к. из вашего ответа следует - что автору надо годик побродить во тьме и понабивать шишки) – Stack Dec 23 '15 at 11:01
  • @Stack перечитайте вопрос внимательнее, а потом спорьте. – andreycha Dec 23 '15 at 11:14
  • "перечитайте вопрос внимательнее" -- перечитал. обратите внимание на слова автора вопроса: "использовал паттерн Репозиторий" -- автор уже использует паттерны. и "закончил реализацию слоя доступа к данным" - автор уже использует слои. и реально пишет код. а вы ему в ответ "забудьте о паттернах на годик. ... получите чуть больше опыта" - не надо забывать, что опыт бывает и негативный. воды/неточностей очень много вокруг. поэтому лучше показать конкретные правильные направления движения/развития. не согласны? пусть набивает шишки как и мы?) а если ему это надоест? или так и задумано?) – Stack Dec 23 '15 at 11:32
-1

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

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

Такой паттерн называется "Cтратегия" -- это изолирование изменяемой части посредством интерфейса.

Для передачи интерфейсов сервисов в бизнес-логику используется инъекция зависимостей (Dependency Injection, DI). Для внедрения зависимостей используются разные способы и целые фреймворки, например, MEF.

Stack
  • 9,452
  • MEF для DI - забивание гвоздей микроскопом. К нему нужно прибегать когда происходит работа с неизвестными типами или плагинами. Для DI лучше юзать тот же autofac\ninject итп. Вообще, при правильном проектировании архитектуры даже инжектор должен быть заменяем. – Мстислав Павлов Dec 22 '15 at 11:00
  • @Bezarius "MEF для DI - забивание гвоздей микроскопом" -- а вы знаете размер и другие условия задачи? и обратите внимание, что перед MEF стоит слово например. – Stack Dec 22 '15 at 11:04
  • кто ставит минусы, пожалуйста, напишите свой вариант ответа. очень интересно. – Stack Dec 22 '15 at 11:14
  • речь не о условиях или конкретно о проекте, а о реализации DI с помощью MEF. Такой вариант, скажем так, несколько специфичный и не является претендентом на универсальность. Если бы вы предложили тот же автофак, у которого есть интеграция с MEF(кстати задумайтесь над этим фактом), я бы вам слова не сказал. А так, у меня есть подозрение, что вы не слишком хорошо разбираетесь в вопросе. – Мстислав Павлов Dec 22 '15 at 11:47
  • @Bezarius "Если бы вы предложили тот же автофак, ... я бы вам слова не сказал." -- если вас устраивает автофак, то это не значит что он подходит всем. и когда говорят "например ...", то это значит, что есть несколько вариантов. – Stack Dec 22 '15 at 11:56
  • @Bezarius "у меня есть подозрение, что вы не слишком хорошо разбираетесь в вопросе" -- если вы разбираетесь, то помогите с ответом на этот вопрос о внедрении зависимости – Stack Dec 22 '15 at 11:58
  • Окей, если бы вы назвали что то из: autofac\ninject\unity, которые как правило используются при реализации DI – Мстислав Павлов Dec 22 '15 at 12:03
  • @Bezarius "если бы вы назвали что то из: autofac\ninject\unity, которые как правило" -- это вы говорите исходя из своего опыта. у вас один опыт, у других - другой. если вы считаете, что мой ответ не полный, то ко мне какие претензии?) напишите свой развернутый ответ. – Stack Dec 22 '15 at 13:08