Почему бы нам не поставить бизнес-логику в сервисах? Будем ли мы когда-нибудь заменять наши услуги?

Question

Я проектирую систему, и я прочитал много статей, в которых говорится, что бизнес-логику не следует включать в код вашего сервиса.И только размещайте свою бизнес-логику в объектах своего домена.

Я нигде не размещаю свой сервисный код, и к нему напрямую обращается мой уровень представления.В будущем я могу захотеть предоставить этот код службы через службу WCF IIS.

Но я не понимаю, почему службы должны быть легковесными?В чем его преимущество?Когда мы когда-нибудь заменим наши услуги?Пожалуйста, объясните

Answer 1

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

Кроме того, его проще тестировать. Вы можете вызвать метод в примере приложения, которое просто вызывает ваш BLL, и вам не нужно беспокоиться о том, чтобы служба вызывала его.

Answer 2

В моем понимании речь идет о соблюдении принципа единственной ответственности .Общая идея заключается в том, что единственной обязанностью вашего уровня обслуживания должен быть перевод операций службы в операции домена.Т.е. вы пишете тип сервиса, который предоставляет метод, представляющий операцию сервиса с контрактом на обслуживание в качестве входных данных.Метод службы переводит операцию службы в операцию домена и позволяет объектам домена беспокоиться о бизнес-правилах.Таким образом, ваш тип инкапсулирует перевод операции службы в операцию домена и ничего более.

Обратите внимание, что я предполагаю, что код службы в статьях, на которые вы ссылаетесь, ссылается на интерфейс службы в сервис-ориентированная архитектура .