Я использую немые бизнес-объекты в своем приложении. Просто использовал DTO для передачи выбранных свойств объекта, но мне интересно, какая разница между ними? Я не могу найти.Разница между объектом передачи данных (DTO) и немым бизнес-объектом?
Может быть немного излишним, но я уже набрал это так hey;)
Чтобы упростить (много), бизнес-объекты должны иметь методы getter/setter, а DTO должен иметь только свойства. Бизнес-объекты должны подчиняться вашим бизнес-правилам, но DTO предназначены только для передачи данных; им не нужно подчиняться каким-либо правилам и должно быть разработано, чтобы как можно быстрее получить данные в них и из них.
В слабо типизированном языке, таком как PHP DTO, не всегда необходимо, так как произвольные свойства могут передаваться родовым объектам «на лету». Тем не менее они могут быть полезны для документации, а также строго типизированных параметров функции.
Я бы сказал, что единственное отличие заключается в намерении, предполагая, что ваши немые бизнес-объекты имеют только состояние и поведение.
В этом контексте:
На самом деле я использовал DTO для привязки объекта, который имел около 30 полей, но я не мог найти никакой разницы между моим DTO и BO только меньше полей/атрибутов. Рекомендуются ли DTO в этом случае, поскольку у меня теперь есть избыточность в моем проекте? –
@Popo - Полностью зависит от вас. Что имеет смысл для вашей заявки? Используете ли вы два аналогичных устройства? Имеют ли они те же обязанности? Существуют ли DTO для развязки? – Oded
Хм, хорошо. Я использую их прямо сейчас, чтобы уменьшить потери памяти в случае больших BO. Еще одно, если бы вы были мной, вы бы использовали DTO для этой цели? –
Когда вы говорите «немые» бизнес-объекты, вы фактически делаете эти объекты такими же, как DTO. Что делает бизнес-объект бизнес-объектом, является добавление валидации и другой функциональной логики. Я не согласен с пользователем «нет», когда он говорит, что бизнес-объекты требуют методов установки и получения; они могут использовать свойства просто отлично, им просто нужно намного больше, чем одно.
Общая точка зрения заключается в том, что бизнес-объектам должно быть разрешено удерживать недопустимые значения и вызывать исключения только при попытке сохранить базу данных, и в этом случае свойства работают отлично. Однако большинство приложений хотят получить обратную связь с пользователем перед попыткой опубликовать в базе данных.
Метод CSLA.NET от Rockford Lhotka заключается в использовании метода IsValid() для бизнес-объекта с набором правил, которые были назначены самому объекту. Существуют и другие способы решения этой проблемы, но ключ заключается в том, что бизнес-объект выполняет проверку. «Тупые» бизнес-объекты на самом деле являются просто DTO, как вы подозреваете.
Спасибо за подробный ответ. Я начинаю получать вещи сейчас =) Спасибо. –
В C# каждое свойство представляет собой пару геттер/сеттер. В этом отношении ваш ответ не имеет особого смысла в области C#. – Oded
@Oded: Я думаю, что ответ имел смысл. Я считаю, что он указывает, что бизнес-объект должен контролировать данные, содержащиеся в DTO. Используя методы getter и setter, а не свойства, вызывающие пользователи с большей вероятностью предполагают, что их данные обрабатываются *, а не просто сохраняются. –