Артем GСервис - это бизнес логика. Все предельно ясно. Но как доходит до практики начинают возникать вопросы.
Как пример: выше я показал репозиторий и сервис. Но то, что написано в репозитории выглядит как бизнес логика, а то, что написано в сервисе выглядит как излишнее...

Я бы не сказал, что сервис -- это бизнес-логика. Сервис, это сервис. Бизнес-логика, это код, который непосредственно решает задачи бизнеса, а именно: комплексные операции обработки и сохранения данных, включая проверку доступа, валидацию, операционные эффекты, генерацию сообщений, вычисления, и прочее... Т.е. всё то, для чего приложение разрабатывается.

Часто бизнес-логику размазывают, особенно по контроллерам, из-за непонимания где такую логику разместить. Сервисы -- это классы, предоставляющие определённые услуги.

Например, сервис данных обеспечивает прикладной код необходимыми данными. Сервис доставки сообщений обеспечивает эту доставку и всё что прилагается. И т.д.

Бизнес-логика, это и есть совокупность всех различных сервисов. Но не всегда архитектура строится на сервисах, есть и другие подходы, которые практически полностью исключают необходимость создания сервис-классов.

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

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

При прототипировании, например, вполне уместно работать прям с DbContext-ом, и прям в контроллерах. Но в серьёзных проектах умные адекватные дядьки, конечно, так делать никогда не будут

ViPRoshVostt,

во каша в башке :)
сервис, бизнес логика :)
сервис - это просто сервис, услуга, которую оказывает сервер, прислуга
бизнес- логика - это просто логика взаимодействия клиентов(тоже могут быть сервисами) и сервисов для достижения целей внесистемных клиентов
главное найти первого внесистемного клиента если ты сервис, дальше сама пойдет :)

Какая каша? Объясни тогда по-другому, потому что я пока не понял из твоих слов что есть что.

Алексей КМестные авторитеты собрались, посовещались и вынесли решение? Браво!

Не путай решение с выводами

Алексей КEF в частности, разрушил всю концепцию репозитариев

С какого он его разрушил? Репозиторий -- абстракция над способом хранения данных, EF это ORM к SQL базе данных (до 7 версии), это ни разу не абстракция и ни разу не репозиторий, а скорее его реализация.

Мда.....

Алексей КhVostt... это ни разу не абстракция и ни разу не репозиторий, а скорее его реализация. ViPRos прав, у тебя каша в голове.

Аргументируй.

skyANAИМХО часть бизнес-логики - это тоже бизнес-логика. :)

Я к тому, что некоторые считают, что сервис-классы это и есть бизнес-логика. В некоторых проектах, видел, такие классы и вовсе называют типа SomeLogic, что в общем-то неплохо, гораздо лучше, чем логика в презентационной инфраструктуре.


skyANAДа, можно нарисовать граф, части которого обвести большими кругами... Но давайте быть проще.

Ну проще и понятнее было бы логику обособлять в отдельном модуле (или в модулях), для многократного использования в различном применении.