Зачем нужен datamapper?

Духовность™

Продвинутый новичок
Зачем нужен datamapper?

В одной из тем прочел следующее: Меня вот сразу насторожил факт присутствия обращения к БД в классах, которые по-моему являются просто контейнерами данных.

Я так понял, что именно для разделения данных объекта (модели) и методов для работы с ними, и придумали DataMapper:
Суть шаблона Data Mapper – это класс, который транслирует атрибуты и/или методы доменного объекта в поля таблицы базы данных и наоборот.
Т.е. грубо говоря класс модели нужно оформить как набор свойств и тривиальных операций типа set/get, а mapper уже должен всё это дело в базу писать.

Так вот, мне не понятно, а в чем западло хранить в одном классе методы для работы с этими данными и их свойства, не делая это разделение?

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

Т.е насколько я понимаю при использовании mapper-s:


PHP:
class User
{
    // свойства класса
    // методы get/set
}
PHP:
class UserMapper
{
    public function save();
    public function delete();
}
PHP:
class UserGroupMapper
{
    public function save_to_group();
    public function delete_from_group();
}
а можно было сделать и так:

PHP:
class User
{
    // свойства класса
    // методы get/set

    public function save();
    public function delete();

    public function save_to_group();
    public function delete_from_group();
}
 

Wicked

Новичок
имхо по single responsibility principle так и должно получаться.
объект в памяти не должен знать о базе данных, о том, как этот объект хранится, и т.д, а только описывать поведение.
 

Духовность™

Продвинутый новичок
Wicked
хорошо. а можно ли в классе модели объявить имена полей таблиц (для того, что бы контролировать атрибуты, которые заносятся в модель)? или это уже отступление от идеологии?

PHP:
class User
{
    // ...
   $this->model_attributes = array('id', 'user_login', 'user_mail');
   // ...
}
 

zuzmic

Новичок
Ну а как получить коллекцию объектов ? , тоже из класса User ?
 

Black Raven

Новичок
http://www.mediafire.com/download.php?bnae2m9xjdy

Patterns of Enterprise Application Architecture.zip (2.03 MB)

---

вообще мне кажется основной смысл сводится к тому, что active record вполне самостоятельный объект и знает о бд, а data mapper убирает из объекта знание о бд. если я не прав - поправьте, я сам нуб в этом вопросе :)

---

вообще наверно стОит перенести тему в теорию :)
 

Духовность™

Продвинутый новичок
вообще мне кажется основной смысл сводится к тому, что active record вполне самостоятельный объект и знает о бд, а DataMapper убирает из объекта знание о бд.
типо того. мы фактически разделили ActiveRecord на два класса. единственная выгода и область применения меппера по сравнению с ActiveRecord, это, как мне кажется, возможность работать с несколькими таблицами, не пихая эту логику в объект модели .

так видимо :confused:
 

Black Raven

Новичок
triumvirat
я ж не просто так дал ссылку на классику :)

вот что написано об active record:
An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.

а вот о data mapper:
Objects and relational databases have different mechanisms for structuring data. Many parts of an object, such as collections and inheritance, aren't present in relational databases. When you build an object model with a lot of business logic it's valuable to use these mechanisms to better organize the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object schema and the relational schema don't match up.

You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the in-memory objects know about the relational database structure, changes in one tend to ripple to the other.

The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.) Since it's a form of Mapper (473), Data Mapper itself is even unknown to the domain layer.

теперь даже я разобрался :-D
 

pilot911

Новичок
тогда ответьте, пож-та, на вопрос - почему в модели нельзя хранить запросы к БД ?
 

zerkms

TDD infected
Команда форума
pilot911
кто сказал, что нельзя? храни, только тогда это не будет DataMapper, а будет ActiveRecord или другой, похожий паттерн.
DataMapper - один из подходов, который подразумевает разделение активной части (маппера, инкапсулирующего логику работы с бд и методами отображения записей рсубд в объекты ЯП и обратно) и пассивной (объекта-контейнера, просто содержащего данные).

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

AmdY

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

whirlwind

TDD infected, paranoid
AmdY +

Давайте не зацикливацо на паттернах. Паттерн - это всего лишь

Паттерн проектирования именует, абстрагирует и идентифицирует ключевые аспекты структуры общего решения, которые и позволяют применить его для создания повторно используемого дизайна. Он вычленяет участвующие классы и экземпляры, их роль и отношения, а также функции. При описании каждого паттерна внимание акцентируется на конкретной задаче ООП. Анализируется, когда следует применять паттерн, можно ли его использовать с учетом других проектных ограничений, каковы будут последствия применения метода.
ISBN 5-469-01136-4, стр. 17

Из этой цитаты, я думаю, можно выделить

1. Паттерн - это роли или функции классов
2. Паттерн - это ООП
3. Паттерн - это задача

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

-~{}~ 04.12.08 04:26:

PS. все просто - если вы думаете, что ваше ООП страдает избыточной декомпозицией, самое время подумать о паттернах. Но не раньше.
 

zerkms

TDD infected
Команда форума
AmdY
это не было вопросом :) я просто привёл пример, провёл аналогию между его "бессмысленным" вопросом, и этим, не более отягощённым смыслом.
 
Сверху