|
|
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
Для добавления связанных сущностей используем код ниже приведденый код, но EF4 есть возможность использования прокси и TracableCollection для отслеживания изменений. Подскажите стоит ли городить ниже приведенный огород или использовать стандартную реализацию EF. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2010, 18:33 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
Слова POCO (PONO) и Persistance ignorance о чём-нибудь говорят? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2010, 20:11 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
SolYUtor, --Слова POCO (PONO) и Persistance ignorance о чём-нибудь говорят? Говорят, из ответа я понимаю, что POCO не подразумевает любого досупа к репозитариям из своих методов. Тогда как правильно заполнять/добавлять/удалять связанные коллекции объектов? Хотелось бы конкретных примеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2010, 21:20 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
Guest04 Говорят, из ответа я понимаю, что POCO не подразумевает любого досупа к репозитариям из своих методов. Тогда как правильно заполнять/добавлять/удалять связанные коллекции объектов? Хотелось бы конкретных примеров. С примерами помочь будет трудно, т.к. EF4 я не использую. Мой выбор - NHibernate. В идеала средство ORM-a должно само заботиться об отслеживании коллекций (NH так и делает путём подмены реализаций коллекций). В своём первом посте упоминали про некий TracableCollection, может быть стоит покопать в эту сторону ,и немного поэкспериментировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2010, 22:04 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
SolYUtor, В принцине и EF все умеет, у меня есть некоторые вопосы: Допусти у клиента 1000 заказов, а хочется загружать скажем по 100 или 50 последних. Где правилно создавать такие методы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2010, 22:46 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
Я бы не стал делать у клиента коллекцию заказов. Их будет слишком много - долго грузить. Односторонняя ассоциацию Заказ -> Клиент для этого случая выглядит предпочтительней. А что бы искать клиентские заказы - сделать набор методов для поиска заказов по клиенту в репозитарии. Например метод, будет возвращать к примеру 50 последних заказов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2010, 22:59 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
SolYUtor, Спасибо, Тогда подскажите как грузить заказы клиенту, т.е. кто вызывает метод репозитария: сам клиент или ...? class Customer { load50Orders() { } } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2010, 10:33 |
|
||
|
Подскажите с архитектурой
|
|||
|---|---|---|---|
|
#18+
Этот вопрос посложнее будет. Т.к. многое зависит от масштабов проекта. Как правильно большая гибкость получается за счёт увеличения сложности. Можно сделать отдельный класс OrderManager, примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2010, 11:34 |
|
||
|
|

start [/forum/topic.php?fid=17&msg=36671652&tid=1351272]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 355ms |

| 0 / 0 |
