Я бы, вероятно, предположил, что вместо того, чтобы строить свои правила валидации на основе форм (например, Zend Framework), вы должны строить валидацию внутри своих доменных объектов. Затем отправьте данные формы непосредственно в объект домена для проверки. Я использую Zend Framework, но я использую эту базовую структуру для своих нужд проверки:
/**
* Contains the domain object properties.
* @var array
*/
protected $_data = null;
/**
* @var array
*/
protected $_filters = null;
/**
* @var array
*/
protected $_validators = null;
public function validate($data = null)
{
if(!$data) {
$data = (array) $this->_data;
} else {
$data = array_merge((array) $this->_data, $data);
}
$this->_input = new Zend_Filter_Input($this->_filters, $this->_validators, $data, $options);
$this->_input->addValidatorPrefixPath('LP_Validate_', 'LP/Validate/');
$this->_input->addFilterPrefixPath('LP_Filter_', 'LP/Filter/');
if($this->_input->isValid()) {
$this->_data = (object) $this->_input->getEscaped();
return true;
} else {
$this->_data = (object) $data;
return false;
}
}
Некоторые ограничения моего текущего подхода с проверкой состоят в том, что я не могу вызвать какие-либо необходимые пользовательские установщики свойств объекта, а также в том, что мне нужно найти способ сохранить исходные данные для объекта доступными после запуска. функция проверки. Но в остальном до сих пор это работало хорошо.
Что касается CRUD, ответ отчасти зависит от сложности проблем, которые вы хотите решить, и отчасти от того, с какими шаблонами вы знакомы, а какие вам нравятся / не нравятся, а какие вы не хотите / не хотите попробуй реализовать.
Очевидно, что наиболее надежный дизайн для реализации - это использование Data Mapper с отдельными доменными объектами, расположенными сверху. Тем не менее, в большинстве случаев это излишне, и поэтому вы можете просто использовать очень (ненадлежащим образом) клеветнический шаблон Active Record. Это в основном то, что CodeIgniter и Zend Framework сделали с тем, что они предоставили.
Мне пришлось создать собственный слой ORM, который использует шаблон Data Mapper, потому что мне нужно было обрабатывать случаи Inheritance Mapping в моем проекте, и он работал довольно гладко, но я сожалею о потере функциональности отображения метаданных, которая пришла с таблицей и реализации Row Gateway в Zend Framework. (Если бы вы могли найти способ эффективно создавать сопоставление метаданных, используя средства отображения данных, я хочу, чтобы вы показали мне, как вы это сделали.: P). Даже при том, что вы пытаетесь создать свой собственный, вы можете рассмотреть Zend Framework, так как он содержит один из лучших PHP-кодов, которые я когда-либо видел, и очень точно следует стандартным шаблонам проектирования.
Одной вещью, которую было бы приятно видеть в классе Pagination, была бы возможность привязки непосредственно к объекту базы данных таким образом, чтобы предложение limit могло быть применено к запросу на основе того, какой диапазон значений должна отображать страница , В противном случае ключевые компоненты с разбивкой на страницы должны отслеживать текущую страницу, количество записей, отображаемых на странице, и какой-либо объект коллекции, содержащий значения, для которых необходимо выполнить итерацию.
По крайней мере, вы хотите убедиться, что не предварительно загружаете всю коллекцию, а затем отображаете только определенный диапазон записей, поскольку это обеспечит огромный удар по производительности.
Что касается запросов Ajax, я бы предложил создать некоторый контекстный помощник, который может проверять, является ли HTTP-запрос XHR или нет, а затем обрабатывать его специально на основе этого контекста.