Компресс Классы DAO слоя

Question

Компресс Классы DAO слоя

0

Я работаю с приложением MVC, которое можно считать большим или средним, оно включает в себя сотни функциональных возможностей и более 400 таблиц на MYSQL. В качестве инструмента ORM мы принимаем зависимость от инъекции доктрины, а также принимаем шаблон DAO (Data Access Object) для хранения запросов для каждого класса Entity, другими словами, каждая таблица имеет класс Entity, а каждый класс Entity имеет DAO класс.

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

Кроме того, все классы DAO являются подклассами класса AbstractDAO, который уже реализует и предлагает общие методы, такие как вставка, обновление, поиск, список и другие.

Что ты предлагаешь для меня? Какой-то технический, шаблон или инструмент для того, чтобы попытаться скомпоновать мой код или, по крайней мере, организовать его лучше?

mayconfsbrito 06 нояб. 2014, в 12:55

Источник

Теги:

php

orm

design-patterns

doctrine

1 ответ

Ещё вопросы

Sebastian Piu · Answer 1 · 2014-11-08T23-13-00.000Z

Трудно сказать, не глядя на код и те запросы, которые вы делаете.

Альтернативой, которую мне нравится подход DAO, является наличие класса для каждого запроса, это должно позволить вам иметь какое-то поведение по тем запросам, которое может уменьшить количество классов, которые вы получаете в конце. Конечно, в худшем случае, если у вас есть 500 запросов, вы закончите с 500 новыми классами, которые могут быть далеки от идеала.

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

Еще одно преимущество заключается в том, что когда вам нужно добавлять новые запросы, вы просто продолжаете добавлять классы и не должны прикасаться к своим уже большим и монолитным DAO

См. Этот вопрос, который я задал некоторое время назад, для С#, но та же концепция должна переноситься на php: Моделирование запросов NHibernate