думал про них, но они сами по себе только предоставляют GUI, а так сказать транспорт для разливки, обычно более низкоуровневый или тот же bash скрипт или deb
видел такой вариант: держат в руте svn копию, когда надо сделать релиз делают svn up. А если делать хранилище ВЫШЕ document_root, то дальше какой алгоритм? svn up потом экспорт в папку с новым релизом?
Обязательно спросите, чем абстрактный класс отличается от интерфейса — как показывает практика, этим вопросом очень легко идентифицировать реальных мидлов.
неужели всё так плохо? Если человек этого не знает, то это вообще не программист (в том языке по крайней мере где такие понятия существуют), это же всегда идет подряд в одном учебнике: Классы — Абстрактные классы — Интерфейсы.
Код, реализующий сохранение связей, должен быть в методах сущности, которая «владеет» этими связями (не в подчинённых объектах).
подумав )), всё таки не могу согласиться с вами до конца. Вариант, когда код привязки располагается в той модели которую привязывают ( и не только модель, но соответствующие шаблоны и контроллеры) имеет очевидные преимущества:
1. Одна и та же модель, как правило привязывается ко всем другим одинаково (по моей статистике), т.е. картинки привязываются одним способом ко всем моделям, теги могут привязываться вторым способом, но всё равно одинаковым для всех моделей.
2. Дисциплинированность разработчиков: описав один раз привязку тегов — можно быть уверенным, что они будут привязываться единообразно ко всем моделям, и таблицы связей с полями будут единообразные.
3. Некоторые модели могут привязываться к десятку других моделей абсолютно одинаково, и в этом случае единственность кода, где это делается, имеет первостепенное значение с точки зрения вероятности ошибок и быстроты внесения правок.
4. Гибкость подключения / отключения новых связей, например, не было сначала тегов, потом появилась в них необходимость — добавили модель и контроллер с кодом привязки и всё — можно привязывать теги к любой модели просто указав у неё наличие связи с тегами ( ну и создав таблицу связей)
Интересно почему во многих примерах про Data Mapper используют явные методы getName(), setName(), а не __get() и __set()?
Еще вопрос, если использовать DM, то где должен располагаться код, реализующий сохранение связей? Вопрос с подковыркой ), к примеру, есть модельTag, теги могут одинаковым способом (меняется только название таблицы связей или fk) привязываться к другим моделям Post, QA, Book. С точки зрения понятности кода, привычнее
$post = new Post;
$post->addTags( [1,2,3] );
$qa = new QA;
$qa->addTags( [1,2,3] );
но с точки зрения дублирования кода, лучше
$post = new Post;
$qa = new QA;
Tag::addTo( $post , [1,2,3]);
Tag::addTo( $qa , [1,2,3]);
Не бейте сильно, хочется разобраться раз и навсегда )).
наверно мы не поняли друг друга, find() — загрузить просто пост без связей, findWithComments — значит загрузить пост с его комментариями
а как ваш пример с этим связан?
неужели всё так плохо? Если человек этого не знает, то это вообще не программист (в том языке по крайней мере где такие понятия существуют), это же всегда идет подряд в одном учебнике: Классы — Абстрактные классы — Интерфейсы.
подумав )), всё таки не могу согласиться с вами до конца. Вариант, когда код привязки располагается в той модели которую привязывают ( и не только модель, но соответствующие шаблоны и контроллеры) имеет очевидные преимущества:
1. Одна и та же модель, как правило привязывается ко всем другим одинаково (по моей статистике), т.е. картинки привязываются одним способом ко всем моделям, теги могут привязываться вторым способом, но всё равно одинаковым для всех моделей.
2. Дисциплинированность разработчиков: описав один раз привязку тегов — можно быть уверенным, что они будут привязываться единообразно ко всем моделям, и таблицы связей с полями будут единообразные.
3. Некоторые модели могут привязываться к десятку других моделей абсолютно одинаково, и в этом случае единственность кода, где это делается, имеет первостепенное значение с точки зрения вероятности ошибок и быстроты внесения правок.
4. Гибкость подключения / отключения новых связей, например, не было сначала тегов, потом появилась в них необходимость — добавили модель и контроллер с кодом привязки и всё — можно привязывать теги к любой модели просто указав у неё наличие связи с тегами ( ну и создав таблицу связей)
Еще вопрос, если использовать DM, то где должен располагаться код, реализующий сохранение связей? Вопрос с подковыркой ), к примеру, есть модельTag, теги могут одинаковым способом (меняется только название таблицы связей или fk) привязываться к другим моделям Post, QA, Book. С точки зрения понятности кода, привычнее
но с точки зрения дублирования кода, лучше
Не бейте сильно, хочется разобраться раз и навсегда )).
а как ваш пример с этим связан?