Компресс Классы DAO слоя
Я работаю с приложением MVC, которое можно считать большим или средним, оно включает в себя сотни функций и более 400 таблиц на MYSQL. В качестве инструмента ORM мы внедряем Doctrine посредством внедрения зависимости, а также принимаем шаблон DAO (объект доступа к данным) для хранения запросов для каждого класса Entity, иными словами, каждая таблица имеет класс Entity, а каждый класс Entity имеет DAO учебный класс.
Я не знаю, нормально ли это, но проблема в том, какие классы DAO становятся большими, в некоторых уже есть более 30 методов, каждый из которых представляет запрос или бизнес-правило.
Мы пытаемся создать методы более широко и параметризованным способом, более того, все классы DAO являются подклассами класса AbstractDAO, который уже реализует и предлагает универсальные методы, такие как вставка, обновление, поиск, список и другие.
Что вы предлагаете для меня? Какой-то технический, шаблон или инструмент для того, чтобы больше сжать мой код или хотя бы лучше организовать его?
Решение
Это довольно сложно сказать, не глядя на код и тип запросов, которые вы делаете.
Альтернатива, которая мне нравится в подходе DAO, состоит в том, чтобы иметь класс для запроса, это должно позволить вам иметь некоторое поведение в этих запросах, которое может уменьшить количество классов, которые вы получите в итоге. Конечно, в худшем случае, если у вас есть 500 запросов, вы получите 500 новых классов, что может быть далеко от идеала.
Опыт показывает, что многие из этих 500 запросов имеют много общего, один и тот же запрос, но дополнительный параметр, тот же запрос, но подкачка страниц и т. Д. Если это соответствует вашему случаю, вы можете сделать свои запросы строителем, который будет использовать большинство кода. Также вы можете переместить некоторые общие вещи в базовый класс запросов и т. Д.
Еще одним преимуществом является то, что когда вам нужно добавить новые запросы, вы просто продолжаете добавлять классы и не должны касаться ваших уже больших и монолитных DAO.
Посмотрите на этот вопрос, который я задал некоторое время назад, для c #, но ту же концепцию следует перенести в php: Моделирование запросов NHibernate
Другие решения
Других решений пока нет …
detector