Разработка более сложных моделей, чем простые модели Db Table - PullRequest
1 голос
/ 02 декабря 2010

Я уже некоторое время использую структуру Zend MVC, но до сих пор мои модели были ограничены только отражением моих отдельных таблиц базы данных.Я не уверен, куда идти, когда дело доходит до написания моделей, отражающих более сложные структуры (например, многие реляционные базы данных).Кто-нибудь знает какие-либо хорошие ресурсы / учебные пособия (желательно онлайн, но также рекомендуют рекомендации по книгам) о том, как подходить к проектированию более сложных моделей?

Ответы [ 2 ]

0 голосов
/ 03 декабря 2010

Звучит так, будто вы готовы к следующему уровню абстракции. Вот 3-х уровневая система:

  1. Уровень данных: на самом деле касается дБ
  2. Уровень бизнес-логики: просто работает с данными, обменивается данными с 1) и 3)
  3. Уровень приложений / контроллеров: принимает входные данные, запрашивает бизнес-логику при любых действиях, никогда не касается непосредственно «неанимированного» уровня данных.

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

См. здесь , чтобы получить немного информации о том, что выходит за рамки вашего текущего подхода. И посмотрите здесь , чтобы узнать немного стратегии относительно уровня бизнес-логики. Они не говорят об отдельном слое данных, но это все же то, что я советую.

Чтобы прояснить общий эффект от повышения удобства сопровождения кода, с помощью этой системы вы могли бы фактически изменить db (MySQL на Postgre все еще был бы PAINFUL, но возможно) и нужно было бы изменить только один слой кода. Кроме того, эта техника позволяет приложениям, таким как PHPBB, поддерживать несколько механизмов баз данных, но при этом использовать как можно больше логики и кода представления. Это также позволит вам поменять пользовательский интерфейс и создать еще один, который взаимодействует с бизнес-объектами, которые реализуют всю бизнес-логику, отдельно от логики контроллера за представлением.

0 голосов
/ 02 декабря 2010

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

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

Текущие решения в большинстве сред - это использование свойств has_many и own_to в моделях. Это решает его проблему, но появляются накладные расходы (множество объектов, тонны простых запросов ...).

Для многих разработчиков это может звучать безумно, но: переписать свои модели.

Сделайте это для облегчения работы композиции / агрегации. Поскольку PHP 5.2+ поддерживает приведение типов (объекты и массивы), вы можете использовать это для написания моделей:

<?php
class Photo extends Model {
  private $id;
  private $src;
  private $description;
}

class Employee extends Model {
  private $id
  private $name;
  private $age;
  private Photo $photo;
}

$x = new Employee(123);
echo $x->photo->description;
?>
...