Это анемичная модель предметной области?

Question

Я пытаюсь создать свое первое приложение CRUD, и я не понимаю, должен ли я использовать объект, содержащий геттеры и сеттеры, разделенные.

Учитывая, что у нас есть Краткое руководство по Zend Framework со структурой Model, содержащей:

• Шлюз
• DataMapper
• Доменный объект (класс модели)

Если объект домена (как представлено в Zend Quick Start Tutorial) состоит только из геттеров и сеттеров, это анти-паттерн? В каком-то смысле мы излишне разделяем объект домена сценарием транзакции?

Пожалуйста, сообщите.

Answer 1

Анемичная модель предметной области является ТОЛЬКО анти-патерновой, ЕСЛИ вы пытаетесь построить истинную модель предметной области (иначе говоря, модель предметной области, основанную на домене), и в итоге получаете сущности только с состоянием и без поведения.

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

См. Статью Мартина Фаулера о Модель анемичной области , а также Статья Грега Янга .

Answer 2

Объекты домена отделены от бизнес-логики программного обеспечения.Это важная идея процедурного программирования .

Однако некоторые разработчики считают, что этот шаблон является антипаттерном, что означает, что он может бытьнеэффективная практика.

На самом деле вы можете учитывать недостатки

• ваша модель менее выразительна, методы получения и установки не очень хороши для описания модели
• код сложнее использовать повторновы получаете дублированный код среди ваших транзакционных сценариев
• вы должны использовать оболочки, которые скрывают фактическую структуру данных (так что, возможно, не совсем ООП)
• всегда есть глобальный доступ к сущностям

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

Я также работал над приложением CRUD с Zend Framework.Четкое разделение между логикой и данными действительно велико, но когда вы прогрессируете, вы понимаете, что количество слоев и картографических карт становится все больше и больше.Старайтесь использовать код как можно чаще и избегайте повторного использования.