|
|
|
ObjectContext in EntityFramework
|
|||
|---|---|---|---|
|
#18+
2 вопроса 1 - "стратегический". Есть БД с кучей таблиц. Как лучше строить модель (и) в проекте? Одну, но большую - на все объекты базы или 10 штук поменьше под конкретные задачи? С точки зрения работы ObjectContext? 2 - При создании аккаунта в системе у меня работает 1 хранимая процедура. Она сразу обрабатывает кучу таблиц. И данные из 6 таблиц выдает тоже одна процедура. При переходе на EF - похоже, надо делать атомарные процедуры для операций crud для каждой таблицы? Тогда получается, что имеем 12 операций входа в БД вместо двух. Или может быть более симпатичное решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2009, 14:08 |
|
||
|
ObjectContext in EntityFramework
|
|||
|---|---|---|---|
|
#18+
NEKRASSOV 1 - "стратегический". Есть БД с кучей таблиц. Как лучше строить модель (и) в проекте? Одну, но большую - на все объекты базы или 10 штук поменьше под конкретные задачи? С точки зрения работы ObjectContext? 2 - При создании аккаунта в системе у меня работает 1 хранимая процедура. Она сразу обрабатывает кучу таблиц. И данные из 6 таблиц выдает тоже одна процедура. При переходе на EF - похоже, надо делать атомарные процедуры для операций crud для каждой таблицы? Тогда получается, что имеем 12 операций входа в БД вместо двух. Или может быть более симпатичное решение? 1 - не знаю как там с точки зрения ObjectContext, но если говорорить чисто про Domain Model + ORM. то здесь нет никаких ограничений, она должна быть такой, какой нужно и не налагает никаких ограничений на что либо. 2 - здесь нет чёткого ответа, что то можно разбить на атомарные действия, что то полезно оставить в СУБД. как правило все CRUD операции после маппинга уже отлично поддерживаются ORM, но порой сложные "R"-операции мапят напрямую на ХП или запрос. Либо строят "правильный" запрос при помощи средств самой ORM, например, - Query, Criteria, MultiCriteria, MultiQuery в Nhibernate. В EF повидимому используются Linq Expression для подобных целей. Код: plaintext Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2009, 18:47 |
|
||
|
ObjectContext in EntityFramework
|
|||
|---|---|---|---|
|
#18+
Sa, Спасибо. Блин, что характерно - Ваш ответ правильный (чувствуется) и грамотный. Но при этом я остался при "своих". В общем, решил так: буду делать несколько моделей с разным составом таблиц. Контексты поменьше будут. И главное - проект гибче. Но, по возможности, постараюсь все-таки "не мельчить" слишком. По поводу процедурок есть одна идея. Попробую - здесь результат сообщу. Вдруг кому тоже интересно будет в будущем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2009, 20:27 |
|
||
|
ObjectContext in EntityFramework
|
|||
|---|---|---|---|
|
#18+
NEKRASSOV2 вопроса 1 - "стратегический". Есть БД с кучей таблиц. Как лучше строить модель (и) в проекте? Одну, но большую - на все объекты базы или 10 штук поменьше под конкретные задачи? С точки зрения работы ObjectContext? Надо небольшими порциями трекинг ObjectContext очень ресурсоемок, посему при показы списка берёте .Execute(NoTracing) и в окне редактировани с трекингом. Разбивку делаете по папка- namespace NEKRASSOV 2 - При создании аккаунта в системе у меня работает 1 хранимая процедура. Она сразу обрабатывает кучу таблиц. И данные из 6 таблиц выдает тоже одна процедура. При переходе на EF - похоже, надо делать атомарные процедуры для операций crud для каждой таблицы? Тогда получается, что имеем 12 операций входа в БД вместо двух. Или может быть более симпатичное решение? Это то же просто решаемая проблема, подумайте чуток и сообразите :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2009, 12:43 |
|
||
|
|
start [/forum/topic.php?fid=17&msg=35782378&tid=1351972]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
66ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 380ms |
| 0 / 0 |
