Я видел много примеров из книг и статей, в которых предлагалось поместить код проверки на уровень обслуживания. Держите объекты домена «немыми» (иначе говоря, чистые POCO) и обрабатывайте все проверки, которые объект домена может выполнять на уровне обслуживания.
Уровень обслуживания несет ответственность за многое (или, по крайней мере, может быть); аутентификация пользователей, аутентификация ролей, сценарии объектов зависимостей для IoC (регистраторы, обработчики ошибок и т. д.), сценарии объектов домена, сценарии репозиториев и передача объектов домена в репозиторий и из него ... уф!
Разве создание всех этих правил на уровне обслуживания не представляет серьезной угрозы для ваших объектов домена? Например, что происходит, когда какой-то программист решает написать потребляющий код непосредственно для ваших объектов домена и просто полностью обходит уровень обслуживания? Это была бы плохая, но правдоподобная ситуация.
Если вы собираетесь возложить много обязанностей на уровень обслуживания, включая всю проверку объектов домена, есть ли способ «защитить» ваши объекты домена, если кто-то пытается напрямую их написать? Например, может быть, каким-то образом ваши объекты домена теперь не используются определенным клиентом (в данном случае уровнем обслуживания?).
Хороший дизайн заставляет меня думать, что объекты домена не должны ничего знать о том, кто им звонит и как они вызываются.
Если нет возможности «заблокировать» объекты домена, то почему так много статей, книг и т. Д. Предполагают, что нужно поместить проверку объекта домена на уровень обслуживания? Я бы предположил, заняв оборонительную позицию программирования, что вы должны создать свои объекты домена, чтобы они были пуленепробиваемыми, и полагаться на свой уровень обслуживания для простого уровня кода для пересылки и получения запросов между пользовательским интерфейсом и BAL / DAL.
Был ли у кого-нибудь в реальной жизни опыт "злоупотребления" объектами домена со стороны людей, которые обошли свой уровень обслуживания?
