ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / EF 6 database views or navigation properties?
5 сообщений из 5, страница 1 из 1
EF 6 database views or navigation properties?
    #39441205
sa13m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sa13m
Гость
WPF + EF 6.1.3(Code first) + PostgreSql. Задача - клиент серверное приложение документооборота, ~100 сущностей.
Каждая сущность наследует:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
    public abstract class ChangeTrackingEntity : BaseEntity, IChangeTrackingEntity
    {
        [Required]
        public DateTime CreateDate { get; set; }
        public DateTime? UpdateDate { get; set; }
        [Required]
        [ForeignKey("CreateUser")]
        public Guid CreateUserId { get; set; }
        [ForeignKey("UpdateUser")]
        public Guid? UpdateUserId { get; set; }

        public virtual User CreateUser { get; set; }
        public virtual User UpdateUser { get; set; }
    }


Для каждой таблицы создается 2 внешних ключа(CreateUserId, UpdateUserId). Правильный ли это подход?
Некоторые сущности имеют более 5 навигационных свойств(внешних ключей), преимущественно связь 1 к 1, в расширении необходимо вывести сущность и все связанные свойства. Вероятно, сущности будут часто модернизироваться. На практике, что лучше:
- создать класс расширение с перечислением всех необходимых свойств
- использовать View из БД?
Как организовать CRUD операции?:
- редактировать ItemsSource(ObservableCollection<ChangeTrackingEntity>)
- обновить ItemsSource из БД?
Хочу минимизировать запросы к БД, но и данные у пользователя должны быть актуальные.
В идеале ищу эталонный пример работы с EF. Благодарю за любую помощь
...
Рейтинг: 0 / 0
19.04.2017, 20:08
| Ответить | Цитировать | Написать  
EF 6 database views or navigation properties?
    #39441242
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
sa13m,

Все эти поля: CreatedDate, UpdateDate, CreatedUserId, UpdatedUserId — по большему счёту бесполезная информация, только засоряющее табличное пространство, и не дающая ничего, что можно хоть как-то применить. Если пользователь создал запись, то следующим апдейтом от записи ничего кроме ID не останется. И что с этой информацией делать? По сути некий пользователь в определённое время создал вот этот ID.

Весь ChangeTracking лучше всего вести отдельно, с полной информацией: кто, что, когда, откуда?

Учитывая, что используется Postgres, подробную информацию о характере изменений можно складывать в JSON поле.

CRUD операции лучше организовать через паттерн Репозиторий. ObservableCollection тебе определённо, совершенно точно, абсолютно не нужен, так как EF итак ведёт свой чендж трекер, не нужно городить огрод поверх него.

А вообще, если хочешь достичь дзена, уменьшить до минимума количество бесполезной бестолковой работы, изучай CQRS/ES/DDD. Для документооборота это очень хорошо подходит.

Да прибудет с тобой сила :)
...
Рейтинг: 0 / 0
19.04.2017, 22:24
| Ответить | Цитировать | Написать  
EF 6 database views or navigation properties?
    #39441245
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
sa13m,

Хотя, если речь идёт о WPF, и характер работы это обычный CRUD с минимальной логикой, можешь работать напрямую с EF/Entity, через какую-нибудь простенькую абстракцию.

Но насчёт IChangeTrackingEntity, убери эти бестолковые поля, кочующие как гнусный паразит из проектов в проект, уже без особых понятий втыкают эти поля, даже не зная как это реально можно использовать.
...
Рейтинг: 0 / 0
19.04.2017, 22:27
| Ответить | Цитировать | Написать  
EF 6 database views or navigation properties?
    #39441271
sa13m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sa13m
Гость
hVostt,

Я не работаю с открытым контекстом, для каждой CRUD операции создаю новый. Использую патерн Repository и UnitOfWork. По CRUD операциям хотел сказать, что если использовать сущность без select new или view (ObservableCollection<Customer> сustomers), то все просто после SaveChanges() -> customers.Add(newCustomer) без лишних запросов к БД, с select new или view не все так просто.
Стоит задача отслеживать любые изменения в любой сущности для этого и ChangeTrackingEntity + таблица History
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
    public class History : BaseEntity
    {
        public string TableName { get; set; }
        public Guid RowId { get; set; }
        public string Type { get; set; }
        public string RowValue { get; set; }
    }

    History history = new History()
    {
        RowId = entity.Id,
        TableName = typeof(TEntity).Name.ToLower(),
        RowValue = JsonConvert.SerializeObject(entity),
        Type = type
    };


Можно отказаться от ChangeTrackingEntity в сущностях и писать все это в History, тогда для получению инфы по изменениям нужно join с History, я думаю это будет накладно. Или Вы предлагаете создать для каждой сущности public string ChangeTracking { get; set; }? В планах еще репликация офис<->подразделения на основе логического декодирования с фильтрацией(готового решения пока не нашел).
...
Рейтинг: 0 / 0
19.04.2017, 23:57
| Ответить | Цитировать | Написать  
EF 6 database views or navigation properties?
    #39441289
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
sa13mСтоит задача отслеживать любые изменения в любой сущности для этого и ChangeTrackingEntity + таблица History

Я понимаю, что стоит такая задача. Я не понимаю, чем тебе помогут поля (CreatedDate, UpdateDate, CreatedUserId, UpdatedUserId), они ни о чём не говорят по сути.


sa13mМожно отказаться от ChangeTrackingEntity в сущностях и писать все это в History, тогда для получению инфы по изменениям нужно join с History, я думаю это будет накладно.

Тебе или шашечки, или ехать :) Ничего не даётся бесплатно.

sa13mне работаю с открытым контекстом, для каждой CRUD операции создаю новый. Использую патерн Repository и UnitOfWork. По CRUD операциям хотел сказать, что если использовать сущность без select new или view (ObservableCollection<Customer> сustomers), то все просто после SaveChanges() -> customers.Add(newCustomer) без лишних запросов к БД, с select new или view не все так просто.

Ты хочешь избавиться от предварительного селекта для обновления? Но в этом есть смысл! Иначе как ты определишь что изменилось и что ты положишь в свой History? Подумай. Если тебе всё равно на хистори, то кроме всего прочего, EF занимается валидацией данных, если там какая-то иерархия, обрабатывает её. В любом случае правильно сначала забрать данные, потом обновить. Ещё к EF можно прикрутить кеш второго уровня, чтобы он не лазил за данными лишний раз. В общем решений масса. И все они чуть-чуть ущербные...

sa13mВ планах еще репликация офис<->подразделения на основе логического декодирования с фильтрацией(готового решения пока не нашел).

Вот тут ничего не понял. Какое ещё декодирование?
...
Рейтинг: 0 / 0
20.04.2017, 02:06
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / EF 6 database views or navigation properties?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=17&msg=39441205&tid=1349302]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 195ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 49ms
get tp. blocked users:
 1ms
others: 14ms
total:  306ms
созд. / загр.: 306ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]