Бобы, методы, доступ и изменение? Какова рекомендуемая практика обращения с ними (т.е. в ColdFusion)?

Question

Я новичок в программировании (сейчас 6 недель). Сейчас я читаю много книг, сайтов и блогов и каждый день узнаю что-то новое.

Сейчас я использую Coldfusion (работа). Я прочитал в Интернете много статей, связанных с oop и cf, и я планирую перейти к mxunit, а затем посмотреть на некоторые фреймворки.

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

Какая рекомендуемая практика для обработки этих данных?

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

Я вижу два варианта.
1. Бин является только хранилищем, другие объекты должны что-то делать со своими данными.
2. Бин - это хранилище и логика, другие объекты говорят ему что-то делать со своими данными.

Второй вариант, как мне кажется, больше привязан к инкапсуляции, а первый - способ использования bean-компонентов.

Я уверен, что оба варианта соответствуют кому-то, и они рекомендуются в определенном контексте, но что рекомендуется в целом, особенно когда кто-то недостаточно знает о более широкой картине приложения и является новичком?

Пример:
Я создал bean-компонент, содержащий элемент из базы данных с идентификатором элемента, именем и 1d-массивом. Каждый элемент массива - это структура, которая содержит пользователя с его идентификатором, именем и количеством элемента. Через геттер я вывожу данные в таблицу, в которой я также могу изменить сумму для каждого пользователя или проверить пользователя на предмет удаления из этого элемента.

Где я могу разместить логику для обработки ввода пользователя приложения?
Могу ли я сказать бину изменить свой массив в соответствии с пользовательским вводом?
Или я создаю объект, который изменяет массив и записывает этот новый массив в bean-компонент?

(Весь доступ к базе данных (CreateReadUpdateDelete) обрабатывается через DataAccessObject, который получает компонент в качестве аргумента. DAO также содержит метод шлюза для чтения более одной записи из базы данных. Я использую этот метод для получения таблицы элементов , который я могу щелкнуть, чтобы создать компонент и его данные.)

Answer 1

Ваш бин должен содержать как ваши данные, так и логику.

Объекты передачи данных используются для передачи объектов по сети, например, из ColdFusion в приложение Flex в браузере. DTO содержат только соответствующие поля данных объекта.

Где возможно, вы должны стараться минимизировать воздействие внутренней реализации вашего компонента (например, массива пользовательских структур) на другие объекты. Чтобы изменить массив, вам нужно просто вызвать мутаторные функции непосредственно в вашем бине, например yourBean.addUser(user), который добавляет структуру пользователя во внутренний массив.

Нет необходимости создавать отдельный DAO с составным объектом Gateway для вашего доступа к данным. Просто поместите все свои методы доступа к базе данных (CRUD плюс табличные запросы) в один объект Gateway.

Answer 2

Вы наблюдаете нечто, известное как "модель анемичного домена" . Да, это очень распространено, и нет, это не хороший ОО дизайн. Обычно логика должна соответствовать данным, с которыми она работает.

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

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