EF. Сохранение/Загрузка "сложных" сущностей в n-tier
От: Аноним  
Дата: 11.06.10 08:32
Оценка:
Привет всем,

разрабатывается распределенное приложение n-tier с использование EF.
Пока только теоретические размышления. Допустим есть три таблицы связанные друг с другом FK:


Родитель -> Ребенок ->   Внук.
--------    -------      -----
ID          ID           ID
            IDРодитель   IDРебенок


получаются примерно следущие сущности:

Родитель -> Ребенок -> Внук
-------- ------- ----


ID          ID         ID
Ребенок[]   Родитель   Ребенок 
            Внук[]


Мне нужно грузить сущьности из бызы, показывать пользователю, обрабатывать, сохранять обратно в базу.
Допустим, следуем следующему сценарию, когда пользователь грузит список детей (ребенок), что бы для начала их увидеть. Одного из них он выбирает, что бы редактировать. И в этот момент, еще не совсем ясно, понядобятся ли ему Родитель и Внук, может быть он не захочеть эти данные менять, а ограничется редактированием данных "ребенка".

Итак, для загрузки списка детей возможно понадобится подобный метод сервиса.
public Ребенок[] GetРебенокList() {
// .. результат отделяется от контекста
}

Не понятно чего когда конкретно грузить. Мне кажется было бы естестенно ограничится списком детей (ребенок), без дозагрузки связанных сущностей.
Допустим пользователь выбирает пользователя для редактирования. Тут бы стоило дозагрузить связанные сущьсности, но как это делать правильно?
Можно попросить сервис:
public Внук[] GetВнукList(Ребенок ID) {
// .. результат отделяется от контекста
}

И присвоить этот список экземпляру Ребенок.

Может было бы лучше, как то делать так:
public ребенок FillВнукLIst(ребенок) {
// подцепляем объект ребенок к "контексту",
// грузим в него внуков
}

Смущает, что нужно передавать весь объект "ребенок", что бы подцепить к нему связанные сущности. Как то криво.

Следующие непонятки возникают, когда необходимо сохранить объект.
Как лучше делать методы сервиса?
Расщиплять объект "ребенок" на составные части? И Вызывать отдельные методы для сохранинея? SaveРебенок(), SAveВнук(), SaveРодитель()

Или вызвать единственный метод SaveРебенок(Ребенок), который как то-сам определяет внутренние связанные объекты, аттачит их в контекст относительно ребенка и сохраняет весь граф данных за один прием.
В этом случае возникают опасения, что если я поменяю угол обозрения, и на сущности буду смотреть со стороны не ребенка, а например внука. То для сохраниения внука SaveВнук, придется заного определять логику добавления внука.

Весь описанный выше бред можно свести к двум вопросам:
— Как организовывать лучше всего дозагрузку связанных сущностей в отделенные от контекста сущности (в распределенных приложениях)?
— Как делать сохранение "сложных" сущностей со связанными данными?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.