Использование XML для класса Model и структурирование

Question

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

Теперь я сижу здесь и не знаю:

---

1.

База данных SQL управляется только моделью с помощью методов, которые программист дает ему, например: «Эй, у нас есть запись name, поэтому нам нужен метод getName()».

OR

2.

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

И должен ли модельный класс проверять каждый / один запрос, является ли это действительным запросом, например, getName() не будет работать на houses_tbl, и если он недействителен, он не выполняет запрос и вместо этого отправляет сообщение об ошибке?

---

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

---

Основные баллы:

• производительность (какой способ экономит наибольшую производительность)
• KISS (этот путь достаточно прост, чтобы второй товарищ по команде мог понять мою логику)
• расширяемость (можно ли расширить структуру)

Answer 1

Проверьте эти Архитектурные шаблоны источника данных : Шлюз табличных данных , Шлюз данных строк , Активная запись , Отображение данных . Для примеров кода для этих шаблонов в PHP вы можете проверить Zend_DB _ *.

Какой шаблон вы должны выбрать, зависит от вашего приложения. Если вы работаете с простым CRUD приложением, вы можете использовать Row Data Gateway. Если вы создаете приложение с большим количеством бизнес-логики из определенного домена , вы, вероятно, выберете другое.

Просто помните, что M в MVC - это не просто уровень постоянства. Модель - это сердце вашего приложения. Controller и View - это всего лишь конец вашего приложения. Дальнейшее чтение Робом Алленом и Мэтью Вейером О'Финни .

Что касается ваших основных моментов, я предлагаю просто придерживаться общепринятых практик. UnitTest ваш код, написать значимый код и документировать его, отдавать предпочтение агрегации, а не составлению, капсуле и отдельным задачам, коду против интерфейса, рефакторингу и т. Д.

Answer 2

Почему бы статически не создать объекты и т.д. во время разработки из базы данных. то есть использовать какое-то Object-Relational-Mapping?

Таким образом, вы создаете Person объект из (скажем) схемы базы данных. Он создает аксессор getName(), и весь ваш код компилируется против этого. Если вы удалите / переименуете поле имени, сгенерированный код изменится, и, следовательно, материал не скомпилируется. Раннее обнаружение этих ошибок спасет вас от многих неприятностей.

В этом вопросе подробно описаны некоторые параметры PHP / ORM. Признаюсь, я не проверял их, чтобы убедиться, что они полностью соответствуют вашим ожиданиям, но, надеюсь, они должны указать вам правильное направление.