powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / repository & aggregate entity
25 сообщений из 305, страница 2 из 13
repository & aggregate entity
    #39564277
Фотография Arpanx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arpanx, ой ошибку отправил.

Код: c#
1.
var department = _vehicleRepository.AllIncluding(x => x.DepartmentVehicles, x => x.VehicleParameters).ToList();



Вот теперь все работает на прямую из репозитория. Всем спасибо.

А Join двух Entity в DTO это предназначено уже для клиента на Ангуляре. Там с ним уже никаких манипуляций не проводят. Только read-only отображают в tree-table.
Я же думаю нормально на сервере уже формировать данные в нужном формате, а не склеивать их на клиенте?
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39564327
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arpanxна Ангуляре. Там с ним уже никаких манипуляций не проводят.
У вам должен быть REST на бэке, чтобы прицепить потом любой фронт. Хоть ангуляр, хоть андроид.
И бизнес логика Либо ангуляре Либо на бэке.
Что у вас под словом манипуляции)) мы не знаем.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39564331
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ArpanxЯ же думаю нормально на сервере уже формировать данные в нужном формате, а не склеивать их на клиенте?
Ангуляр это утром загрузил и 8 часов ходишь по страницам, работаешь.
Как можно склеить сервере то что понадобится вечером?
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39564343
Фотография Arpanx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123,

Хм, звучит логично. У меня в принципе REST и есть. Но похоже кривой.

Сделать REST Endpoint как продожение Entity из репозитория в принципе это правильное решение.
Щас, надо подумать как это будет работать со стороны клиента. Спасибо за дельное замечание.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39564354
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arpanx,
Замени ангуляр.
Мы в топике шарп. А ангуляр для топика js программист.
Ты не потянешь боливар за двоих.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39564642
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ArpanxGeneric Repository вроде делали умные люди, чего-то не хватает. Разбираюсь.

Generic Repo подойдёт только, если у вас модель данных отлично нормализована, таким образом, что вам никогда не понадобится JOIN между двумя корнями агрегатов, если они вообще у вас получатся выраженными.

Так что, если вам «чего-то нехватает», то здесь одно из двух:

1. Плохо нормализованная модель, перепроектировать
2. Бизнес не укладывается в нормализацию модели, вам не подойдёт Generic Repo.

Ещё 3 вариант: Generic Repo, как стандартная реализация, делаете для конкретных случаев конкретные интерфейсы репо с конкретной реализацией, где выжимаете весь power из своего DbContext-а.

И ещё 4 вариант: Query Object (QO), или какие-то вариации спецификаций (которые на мой взгляд чуть менее, чем полностью ущербны). Но это уже досвидос genrepo и вообще от репо остаётся только add/update/remove, но ни в коем случае никаких построений запросов.

QO можно смонстрячить на LINQ, через Expression tree, это опять же ковыряния, костыли, на любителя (например, местный гуру Алексей К любитель LINQ).

Любой вариант хорош, применительно к своей задаче.

Я делал genrepo много раз, но в ограниченном контексте, большую систему строить на этом я бы не стал никогда и даже за большие деньги. Ну может за очень большие бы и стал.. нанял бы пару студентов, пусть бы долбались
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39566083
pet_trow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hVosttArpanxGeneric Repository вроде делали умные люди, чего-то не хватает. Разбираюсь.

Generic Repo подойдёт только, если у вас модель данных отлично нормализована, таким образом, что вам никогда не понадобится JOIN между двумя корнями агрегатов, если они вообще у вас получатся выраженными.

Так что, если вам «чего-то нехватает», то здесь одно из двух:

1. Плохо нормализованная модель, перепроектировать
2. Бизнес не укладывается в нормализацию модели, вам не подойдёт Generic Repo.

Ещё 3 вариант: Generic Repo, как стандартная реализация, делаете для конкретных случаев конкретные интерфейсы репо с конкретной реализацией, где выжимаете весь power из своего DbContext-а.

И ещё 4 вариант: Query Object (QO), или какие-то вариации спецификаций (которые на мой взгляд чуть менее, чем полностью ущербны). Но это уже досвидос genrepo и вообще от репо остаётся только add/update/remove, но ни в коем случае никаких построений запросов.

QO можно смонстрячить на LINQ, через Expression tree, это опять же ковыряния, костыли, на любителя (например, местный гуру Алексей К любитель LINQ).

Любой вариант хорош, применительно к своей задаче.

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

нехилый разброс :)
hVostt, а Вы не могли бы, ну, чисто по-опыту (пожалуйста!!!!), свое видение/применимость DDD тезисно обозначить? я, например, как и ТС, тоже в поисках этого "тут же DDD!!!". но пока его не нахожу за "деревьями" вот этих всех Вами перечисленных вариантов: "леса не вижу"
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39566218
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pet_trowнехилый разброс :)
hVostt, а Вы не могли бы, ну, чисто по-опыту (пожалуйста!!!!), свое видение/применимость DDD тезисно обозначить? я, например, как и ТС, тоже в поисках этого "тут же DDD!!!". но пока его не нахожу за "деревьями" вот этих всех Вами перечисленных вариантов: "леса не вижу"

А чё его искать? Это просто дизайн архитектуры и прикладной логики в терминах, приближённых к бизнесу. За подробностями лучше обратиться к тематической литературе :)

Ну или что-то конкретное можно обсудить..
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39566379
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pet_trow. но пока его не нахожу за "деревьями
Это когда, вместо голых сущностей (класс копия таблицы) делают ещё классы сверху чтобы не трогать классы сущности внизу.
Увидели такое в лесу? ).
"Лекарство имеет побочные эффекты."
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39566990
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Это когда, вместо голых сущностей (класс копия таблицы) делают ещё классы сверху чтобы не трогать классы сущности внизу.

это называется DTO
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567521
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttPetro123Это когда, вместо голых сущностей (класс копия таблицы) делают ещё классы сверху чтобы не трогать классы сущности внизу.

это называется DTO
приехали.
DTO ещё выше.
Я о таких паре классов:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Сущность Юзверь {
   int ID
   date ДатаРождения
}

Сущность ЮзверьБизнесЛогика {
    int ID
    public bool ЕстьЛиЗадолженность(){
      ....
    {
}
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567531
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123приехали.
DTO ещё выше.
Я о таких паре классов:

любой класс, созданный для того, чтобы гонять данные между подсистемами может по праву считаться DTO
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567544
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttPetro123приехали.
DTO ещё выше.
Я о таких паре классов:
любой класс, созданный для того, чтобы гонять данные между подсистемами может по праву считаться DTO
неа)
DTO это простейший класс без методов бизнес-логики.
По факту тот JSON если есть то можно обойтись без DTO.
Или передача инфы через URL еси есть, то тоже можно DTO выкинуть.
..
Мы вообще тут про агрегацию сущностей для бизнес логики НА сервере.
IMHO
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567546
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttчтобы гонять данные
он не для гонять
Код: c#
1.
2.
3.
4.
5.
6.
Сущность ЮзверьБизнесЛогика {
    int ID
    public bool ЕстьЛиЗадолженность(){
      ....
    {
}
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567576
Фотография Arpanx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скорее всего будете кидаться тапками, но решил пока делать так:

DBContext -> Service -> (тут на выходе композитные типы ) -> WebApi Comtoller/REST

Т.е. на выходе REST будут мои доменные типы которыми оперирует моя программа на клиенте.
От репозитория пока отказался, не получается с репозиторием делать тоже что с DBContext.

Параллельно смотрю на реализацию CloudFireStore облачная база данных noSQL от гугла. Там есть своя красота. За данными не нужно ходить, они сами к вам на клиента постучаться, можно подписываться на события в базе. А денормализацию можно рассматривать как композитный тип. Только за целостностью базы приходится самому следить с помощью кода на клиенте.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567582
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ArpanxОт репозитория пока отказался, не получается с репозиторием делать тоже что с DBContext.Есть мнение, что DbContext и есть репозитарий.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567597
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ArpanxDBContext -> Service -> (тут на выходе композитные типы ) -> WebApi Comtoller/REST
Есть мнение, что если у вас современная модель БД с грамотной денормализацией, то можно сразу сущности БД в виде классов выставлять в REST.
Я не в курсе, есть ли в MS REST фреймворк (в Java он есть), тогда никакие сервисные слои и прослойки не нужны.
При REST технолгии вся логика на клиенте. А СУБД-импотент тупо передаёт ДАННЫЕ.

Arpanxбаза данных noSQL
это оффтоп
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567814
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123DTO это простейший класс без методов бизнес-логики.

видимо ты путаешь с POCO? )

DTO может быть даже обычным Dictionary, и у нас, кстати, в текущем проекте в основном именно такие DTO, никаких статических классов не может быть и в помине, если у тебя все модели создаются пользователями.


Petro123По факту тот JSON если есть то можно обойтись без DTO.

JSON это тоже DTO
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567816
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КArpanxОт репозитория пока отказался, не получается с репозиторием делать тоже что с DBContext.Есть мнение, что DbContext и есть репозитарий.

DbContext это и репозиторий, и UOW, и кеширование, и валидация, и генерация SQL, и миграции и...
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567851
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttвидимо ты путаешь с POCO? )
нет)
Как только их не называют))
https://ru.wikipedia.org/wiki/POJO
это в Java

hVosttDTO может быть даже обычным Dictionary
не понял зачем.
Мы передаём справочник через веб на другой континет. Зачем логику списка...уникальности.....вставки...удаления тащить через океан?
Класс Dictionary ИМЕЕТ ЛОГИКУ!
hVosttесли у тебя все модели создаются пользователями.
вопрос где она создаётся. На сервере или клиенте в ангуляре.
Понятно, что у тебя предметка на работе сложнее.....много динамики.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39567855
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttJSON это тоже DTO
)))
угу. А палка это дерево из одной ветки)).
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39568463
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123не понял зачем.
Мы передаём справочник через веб на другой континет. Зачем логику списка...уникальности.....вставки...удаления тащить через океан?
Класс Dictionary ИМЕЕТ ЛОГИКУ!

Затем, что объект с набором [свойство=значение,...], это по сути и есть словарь.
Ты его итак потащишь через "океан" в каком-то виде. Если этот вид Dictionary, а точнее IReadOnlyDictionary или ImmutableDictionary -- это зашибись вообще!

Мы же обсуждаем, что класс в C# это целая хренотень со ссылкой на тип, и контекстом синхронизации под пристальным взглядом GC? Как словарь, так сразу «логика», а экземпляр класса это что, хрен собачий?

Petro123)))
угу. А палка это дерево из одной ветки)).

В определении DTO ни разу не сказано, что это класс. Это любой объект без поведения. Под поведением обычно понимают бизнес-логику, а не базовые алгоритмы, необходимые для функционирования самого объекта.
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39568823
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttЗатем, что объект с набором [свойство=значение,...], это по сути и есть словарь.
дак всё таки, объект-класс или JSON со строкой?

hVosttЕсли этот вид Dictionary, а точнее IReadOnlyDictionary или ImmutableDictionary -- это зашибись вообще!
не согласен. Один сервер и тыЩи клиентов. Какие интерфейсы?

hVosttВ определении DTO ни разу не сказано, что это класс.
моё имхо в том, что это объект в памяти для дальнейшей трансформации в JSON.
Иногда ЭТО вообще не нужно и устарело.

hVosttЭто любой объект без поведения. Под поведением обычно понимают бизнес-логику, а не базовые алгоритмы, необходимые для функционирования самого объекта.
нет. Не люблю мешать понятия. Мухи отдельно....
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39568971
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123дак всё таки, объект-класс или JSON со строкой?

ну объект какой-то, из которого можно извлечь данные

Petro123не согласен. Один сервер и тыЩи клиентов. Какие интерфейсы?

ну пусть будет, контракт

Petro123моё имхо в том, что это объект в памяти для дальнейшей трансформации в JSON.
Иногда ЭТО вообще не нужно и устарело.

словарь отлично трансформируется в JSON и обратно :)

Petro123нет. Не люблю мешать понятия. Мухи отдельно....

у каждого свои загоны
...
Рейтинг: 0 / 0
repository & aggregate entity
    #39568997
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttну пусть будет, контракт
Тогда приводи примеры что за волшебные слова "контракт" мы посылаем со списком городов
ИндексПочты Имя
hVosttPetro123моё имхо в том, что это объект в памяти для дальнейшей трансформации в JSON.
Иногда ЭТО вообще не нужно и устарело.

словарь отлично трансформируется в JSON и обратно :)
угу. Осталось выяснить какой толщины должен быть список городов чтобы обозвать его не DTO а бизнес объект.
...
Рейтинг: 0 / 0
25 сообщений из 305, страница 2 из 13
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / repository & aggregate entity
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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