#entity-framework-4 #repository-pattern #objectquery
#entity-framework-4 #репозиторий-шаблон #objectquery
Вопрос:
Вопрос, касающийся шаблона репозитория и шаблона объекта запроса. Я использую EF 4 и сгенерировал свои классы POCO из моей модели базы данных, используя ADO.NET Генератор сущностей POCO в VS 2010. Файл edmx и файл tt (классы POCO) находятся в двух разных проектах.
Мои репозитории зависят от домена, например DocumentRepository и UserRepository. Моя модель базы данных отличается от моей модели домена в такой степени, что я внедрил картографы, чтобы преобразовать объект домена в одну или несколько таблиц базы данных (и наоборот). Одним из примеров является то, что мой класс домена Document моделируется как 3 таблицы (и, следовательно, классы POCO) в базе данных.
Как бы вы реализовали шаблон объекта запроса при использовании объектов домена в таком случае? Насколько я понимаю, мне придется написать базу объектов запроса на классах POCO, а не на классах домена? Но не нарушит ли это шаблон репозитория?
Комментарии:
1. entity-framework 4.1 позволяет разделить объект на несколько таблиц. Таким образом, это не нарушило бы шаблон репозитория.
Ответ №1:
ORM обычно используется таким образом, что он работает непосредственно с объектами домена = он загружает их из базы данных и сохраняет их в базе данных. Вы выполняете еще один шаг абстракции, на котором вы используете объекты ORM только для заполнения ваших пользовательских объектов. Ваши пользовательские объекты полностью выходят за рамки вашего инструмента ORM, и вы не можете ожидать, что инструмент ORM предоставит вам какую-либо поддержку для запросов, построенных поверх объектов вашего домена. Вы должны создать собственную поддержку запросов и преобразовать запросы домена в запросы ORM внутри ваших репозиториев. Обычно это делается путем реализации шаблона спецификации.
Кстати. в таком сценарии POCOs не имеет слишком большого смысла — POCOs предназначены для сценариев, где вы хотите использовать их в качестве объектов домена).
Комментарии:
1. Я понимаю, что мои усилия по реализации шаблона репозитория создают несколько сложный дизайн, поскольку я не хочу использовать мои классы POCO в моей презентации и бизнес-уровне. Я чувствую, что они не моделируют мой домен так, как должны, и именно поэтому я начал использовать классы домена. Я не могу понять, почему шаблон спецификации — это правильный путь здесь, но тогда я не использовал его раньше.
2. Спецификация позволит вам определить запрос так, как вам нужно, поверх вашей модели домена, и вы переведете его в запрос EF, необходимый для EF в репозитории.
3. Итак, тогда мне нужно также написать логику перевода из запроса домена в запрос EF.. Я не уверен, что у меня есть время на все это, и это значительно усложняет ситуацию. Если я использую классы POCO в спецификации и пишу запросы к ним, я разрушаю границы слоя, верно? В конце концов, моей целью было скрыть модель данных с помощью объектов домена. Возможно, мне следует пересмотреть использование шаблона репозитория в этом проекте.
4. Но именно так вы создавали свой дизайн. Вам нужны пользовательские запросы с пользовательскими объектами? Если ответ положительный, вы должны создать «описание запроса» = шаблон спецификации, который будет передан в репозиторий (= следующий шаблон, в котором говорится, что пользователь задает запросы декларативным способом), и репозиторий должен обрабатывать все сложности. Если вам это не нравится, потому что это сложно, тогда предоставьте POCOs из своих репозиториев вместо пользовательских объектов домена и используйте linq-to-entities напрямую. В пользовательском интерфейсе вы можете использовать пользовательские модели представления или другие классы, ориентированные на представление, загруженные из POCOs.
5. Что ж, я хотел, чтобы запросы размещались поверх объектов моего домена, чтобы сделать мой дизайн более гибким, но теперь я начинаю сожалеть об этом 🙂 Возможно, мне следует написать конкретные методы в моих репозиториях, которые делают именно то, что я хочу, вместо более общего подхода. Это упростит работу (но увеличит объем репозиториев). Я думаю, здесь есть урок, который следует усвоить! 🙂 Спасибо, что ответил на мои вопросы, Ладислав! Продолжайте хорошо работать над stackoverflow!