Шаблон репозитория с lazying, загружающимся использующий ПОСТЕПЕННО
Я нахожусь в процессе запуска нового проекта и создания бизнес-объектов и доступа к данным и т.д. Я просто использую простые объекты сброса, а не любой orms. Я создал две библиотеки классов: 1) Бизнес-объекты - содержат все мои бизнес-объекты, все это возражает, легкий вес только со свойствами и бизнес-правилами. 2) Репозиторий - это для всего моего доступа к данным.
У большинства моих объектов будет дочерний список в, и мой вопрос - то, что является лучшим способом к ленивой загрузке эти значения, поскольку я не хочу возвращать ненужную информацию, если я не должен.
Я думал о при использовании "получения" на дочернем свойстве, чтобы проверить, если его "пустой указатель" и если это - вызов мой репозиторий для получения дочерней информации. Это имеет две проблемы от того, что я вижу: 1) Объект, "знает", как вовлечь себя, я быть не бы никакая логика доступа к данным быть сохраненным в объекте. 2) Это потребовало, чтобы оба класса сослались друг на друга, который в Visual Studio бросает круговую ошибку зависимости.
У кого-либо есть какие-либо предложения о том, как преодолеть эту проблему или какие-либо рекомендации на моем расположении проектов и где это может быть улучшено?
Спасибо
4 ответа
Изучив предоставленные ответы и проведя дополнительные исследования, я нашел статью, в которой делегаты используются для отложенной загрузки. Это было более простым решением, чем использование прокси или реализация NHibernate.
Вот ссылка на статью.
Вы можете обойти проблему циклической зависимости, если ваш код отложенной загрузки загружает репозиторий во время выполнения ( Activator.CreateInstance или что-то подобное) а затем вызывает соответствующий метод через отражение. Конечно, рефлексия снижает производительность, но часто оказывается незначительной в большинстве решений.
Другой способ решить эту проблему - просто скомпилировать в одну dll - здесь вы по-прежнему можете логически разделить свои слои, используя разные пространства имен, и по-прежнему организовывать свои классы, используя разные каталоги.
Для этого требуется, чтобы вы программировали интерфейсы (абстракции над реализациями) и / или объявляли свои свойства виртуальными. Затем ваш репозиторий возвращает прокси-объект для тех свойств, которые должны загружаться лениво. Класс, который вызывает репозиторий, ничем не мудрее, но когда он пытается получить доступ к одному из этих свойств, прокси вызывает базу данных и загружает значения.
Честно говоря, я считаю безумием пытаться реализовать это самостоятельно. Существуют отличные, проверенные временем решения этой проблемы, которые были разработаны и усовершенствованы величайшими умами .NET.
Для выполнения проксирования вы можете использовать Castle DynamicProxy , или вы можете использовать NHibernate и позволить ему обрабатывать все проксирование и отложенную загрузку за вас (он использует DynamicProxy). Вы гарантированно получите лучшую производительность, чем любая ручная реализация.
NHibernate не будет связываться с вашими POCO - ни атрибутов, ни базовых классов; вам нужно только пометить участников как виртуальные, чтобы разрешить создание прокси.
Проще говоря, я бы пересмотрел вариант использования ORM, особенно если вам нужна отложенная загрузка; вам не нужно отказываться от своих POCO.
Если вы используете Entity Framework 4.0, у вас будет поддержка POCO с отложенной загрузкой и вы сможете написать общий репозиторий для выполнения доступ к данным.
В Интернете есть масса статей об общем шаблоне репозитория с EF 4.0
HTH.