Ленивая Загрузка Набора - как получить объекты?

Если вы можете подождать .Net 4 (т.е. вы еще не в производстве), то Lazy(of T) - это новая функция Lazy Loading в .Net фреймворке. http://msdn.microsoft.com/en-us/library/dd642331(VS.100).aspx

Вы нарушаете все назначение DTO, когда пытаетесь добавить к ним логику ленивой загрузки. Я думаю, что у вас должны быть два отдельных объекта: один с Notes, а другой -- без них.

] После блуждания по астральным мирам для эонов в отчаянном поиске ответа, я пришел к окончательному выводу, что да, нет необходимости передавать хранилище в экземпляр вашей сущности, потому что хранилище для типа сущности всегда должно быть одноэлементным. [

]Чтобы вы могли написать в вашем сущностном классе что-то вроде:[

public class Monster
{
    public ReadOnlyCollection<Victim> _victims;
    public ReadOnlyCollection<Victim> Victims
    {
        get
        {
            if (this._victims == null) // Note: Thread-Safety left out for brevity
            {
                this._victims = VictimRepository.Instance.GetVictimsForMonster(this);
            }

            return this._victims;
        }
    }
}

]Это действительно решило все головные боли для меня.[

]Репозиторий должен быть реализован таким образом, чтобы он всегда знал, что делать с данными.[

]Помните, что одна реализация репозитория, например, будет получать данные из базы данных, в то время как другая может получать их из веб-сервиса. Из-за отсутствия связи, модуль реализации репозитория легко заменяется, а любое взаимодействие с данными даже произвольно цепляется. [

]Если у вас есть сценарий, в котором вы говорите "но репозиторий не может быть однокнопочным, потому что у меня есть сложный сценарий, в котором я, например, получаю доступ к нескольким источникам данных, и это зависит от фактического экземпляра []Monster[], откуда можно получить []Victim[]s", то я говорю, что вы должны создать такую реализацию репозитория, которая знает все источники данных и отслеживает, откуда приходят и куда уходят экземпляры сущностей, и так далее. ...[

]Если вам кажется, что этого подхода недостаточно для POCO, то вы должны создать другой свободно связанный Уровень Бизнес Логики, который обёртывает или извлекает из сущности POCO и реализует там взаимодействие с репозиторием.[

]Надеюсь, я смогу дать подсказку в направлении, которое кажется подходящим для вас и для любого другого человека. Я действительно верю, что это священный грааль для многослойной/уровневой разработки. Не стесняйтесь обсуждать это дальше.[

] В качестве параметра в INoteRepository можно использовать свойство Notes. Таким образом, код вызова может быть передан в корректном экземпляре INoteRepository.[

Другой вариант - использовать прокси, которые наследуют от объектов, которые вы хотите получить (после проведения некоторых объектов-реляционных материалов, таких как NHIBERNATE).

Это обеспечивает незнакомое значение настойчивости, поддерживая код доступа к данным отдельно от модели домена:

public class MyLazyDTOClass: MyDTOClass {   

    // Injected into the constructor by the MyDtoClass repository
    private INoteRepository noteRepository;        

    public ICollection<Note> Notes {
        get {
            if(base.Notes == null) {
                base.Notes = noteRepository.GetNotes(projectId);
            }
            return base.Notes;
        }
    }
}

MyDToclassRepository объявляет базовый объект в качестве возврата, но возвращает ленивый объект вместо этого:

public MyDTOClassRepository {
    public MyDTOClass GetMyDTOClass(int id) {
        // ... Execute data access code to obtain state ...
        return new MyLazyDTOClass(this, state);
    }
}

MyDToclass Потребители не нужно знать, что они имеют дело с прокси, и они не должны взаимодействовать с репозиториями (за исключением того, что любой класс делает первоначальный звонок курса).

Вы не можете добиться независимости от вашего репозитория, если вы ленивы от нее Отказ Вы можете сохранить его на расстоянии ARM, используя обратный вызов или прокси или позволить Nibernate сделать грязную работу для вас, но ваш DTO должен получить доступ к репозитории для загрузки заметок.

Ваша главная цель, по-видимому, «я хочу, чтобы это было похоже на поговорку на внешний абонент, поэтому я люблю иметь свойство« заметки », а не методы, такие как« getnotesforProject »на этом или другим классам. Разве вы не можете достичь этого с инъекцией Ninject и Constructor? Как только вы настроите Ninject, вы можете вызвать Kernel.get (), чтобы получить новый экземпляр, который не будет подвергать ссылку на ваш репозиторий.