powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Архитектура приложения, надо ли дублировать сущности под каждый слой
295 сообщений из 295, показаны все 12 страниц
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085289
blest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В моем понимании схема проекта должна быть такой:



Получается в данной схеме на одну сущность БД (Entity) мы дважды дублируем данную сущность для других слоев - для BLL и для слоя приложения.

1) Правильно ли я все понимаю схему
2) допускается ли наследование DataModel От Entity или лучше независимые классы создать
3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085308
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blest,

лучше использовать модель , а остальное пофиг
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085311
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
назовите:
DataModel - DTO

Model - ViewModel

BLLayer - DataService

и по схеме:

DTO от Entity не зависит, Entity может вообще отсутствовать

DataService и Repository зависит от DTO
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085314
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blest2) допускается ли наследование DataModel От Entity или лучше независимые классы создать

только независимые
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085315
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую

можно, но я не видел ни одного проекта, когда это дало бы профит
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085319
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawblest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую

можно, но я не видел ни одного проекта, когда это дало бы профит
а какие ты проекты воще видел? (давай погавкаемся)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085325
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoskmawпропущено...


можно, но я не видел ни одного проекта, когда это дало бы профит
а какие ты проекты воще видел? (давай погавкаемся)

на такой чОткий вопрос так сразу и не ответишь.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085328
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw,

ну давай почетче
что там ДатаМодел и что там ентити
и почему чувиха хочет датамодел из ентити наследовать?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085331
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoskmaw,

ну давай почетче
что там ДатаМодел и что там ентити
и почему чувиха хочет датамодел из ентити наследовать?

"и почему чувиха хочет датамодел из ентити наследовать" - он думает, что это копипаст. он заблуждается. пример:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
class SomeEntity
{
public long Id {get; set}
public IList<SomeEntity1> List {get; set}
}

class SomeDTO
{
public long Id {get; set}
public IList<SomeDTO11> List1{get; set}
public IList<SomeDTO12> List2{get; set}
public IList<SomeDTO13> List3{get; set}
}


где,

Код: c#
1.
2.
3.
class SomeDTO11: SomeDTO1
class SomeDTO12: SomeDTO1
class SomeDTO13: SomeDTO1
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085338
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosлучше использовать модель , а остальное пофиг

читал твои мысли в разных топиках на эту тему. ты вкладываешь в этот термин свое ViPRos-вское понятие модели. тут все более прозаично
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085373
Roman Mejtes
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
лично я так и делаю.
в солюшене есть проект слоя данных, в нем все сущности базы и сервисы для загрузки,
в другом проекте поставщики данных (Provider), классы которые используя серверы предоставляют доступ к observable коллекциям, обновляют их и т.д.
в третьем проекте модели представления и как правило сразу же рядом с ними View'и (XAML ресурсы, без CodeBehind, я использую только шаблоны (DataTemplate), стили и если надо спец. панели и контролы, но часто панели и контролы тоже выношу в отдельный проект.
После этого, остается только в ViewModel получить из поставщика нужную коллекцию, из поставщика я уже получаю объекты для ViewModel, а о слое данных ViewModel особо и не в курсе. По сути Provider'ы, это часть ViewModel'и но вынесенная отдельно.
Мне так удобно, во первых. Мне не нужно париться об обновлении данных в ViewModel, так как всё это вынесено в Provider'ы, провайдер сам создает ObservableCollection<T>, сам регулярно подключается к базе и проверяет, не обновился ли список, вставляет и удаляет записи и создает. Делается всё это при помощи сервисов
Да писать приходится больше, но в дальнейшем я только выигрываю.:
а) сервисы для загрузки из бд у меня универсальные и сделаны на базе рефлексии, то есть загрузка происходит автоматом, нужно только для класса определяющего сущность записи бд прописать нужные аттрибуты или задать правильно имена свойство по полям.
Если я работаю с БД.
б) загрузка данных происходит только 1 раз, разные модели представления могут получить доступ к одному поставщику данных, мне не надо каждый раз заботится о всех сопутствующих проблемах.

Как по мне, делать нужно так, как удобно и легко.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085374
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blest1) Правильно ли я все понимаю схему

Если под «правильно» понимается «мы дважды дублируем данную сущность», то нет. Ибо, что такое сущность? Табличка в базе данных? Сущность в контексте репозитория / ORM, отражает то, как данные хранятся, немного скрывая свою реляционную природу. В теории, сущности могут лежать вовсе не в реляционной структуре, а в какой-нибудь NoSQL, или ещё где-то, и нам это должно быть не важно. Но это всё лирика, и лежит в плоскости более практичной — мы прекрасно знаем где и как данные будут лежать, всё что слой доступа к данным делает, это типизирует эти данные, ну и немного (совсем немного), скрывает конкретику природы хранилища. Т.е. MS SQL мы можем заменить на какой-нибудь Oracle, и это должно прокатить.

А под DataModel понимается скорее всего DTO — это конкретные кортежи данных, которые вовсе не обязаны соответствовать табличкам. Например, у тебя есть некий грид и 10 колонок, чтобы их получить, надо собрать данные из 5 таблиц, вот и выбирай: либо 5 сущностей, либо 1 DTO. А как 5 сущностей превратить в 1 DTO? Ответ — проекция, чувак. Проекция! :)

В общем, ответ на первый вопрос: скорее нет, чем да.

blest2) допускается ли наследование DataModel От Entity или лучше независимые классы создать

Нет! Не допускается. Даже не вижу смысла отвечать на вопрос «почему?», ведь эти классы служат совершенно разным целям и решают разные задачи.

blest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую

Можно со временем состряпать свой некий bootstrapper, который будет содержать каркас, с которым удобно работать. Если каркас получился удачным, то большая часть предметной области может в него удобно лечь. Ну а это уже приходит с опытом. Ну и задачи со временем становятся довольно таки однотипными.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085377
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman Mejtesлично я так и делаю.
в солюшене есть проект слоя данных, в нем все сущности базы и сервисы для загрузки,
в другом проекте поставщики данных (Provider), классы которые используя серверы предоставляют доступ к observable коллекциям, обновляют их и т.д.
в третьем проекте модели представления и как правило сразу же рядом с ними View'и (XAML ресурсы, без CodeBehind, я использую только шаблоны (DataTemplate), стили и если надо спец. панели и контролы, но часто панели и контролы тоже выношу в отдельный проект.
После этого, остается только в ViewModel получить из поставщика нужную коллекцию, из поставщика я уже получаю объекты для ViewModel, а о слое данных ViewModel особо и не в курсе. По сути Provider'ы, это часть ViewModel'и но вынесенная отдельно.
Мне так удобно, во первых. Мне не нужно париться об обновлении данных в ViewModel, так как всё это вынесено в Provider'ы, провайдер сам создает ObservableCollection<T>, сам регулярно подключается к базе и проверяет, не обновился ли список, вставляет и удаляет записи и создает. Делается всё это при помощи сервисов
Да писать приходится больше, но в дальнейшем я только выигрываю.:
а) сервисы для загрузки из бд у меня универсальные и сделаны на базе рефлексии, то есть загрузка происходит автоматом, нужно только для класса определяющего сущность записи бд прописать нужные аттрибуты или задать правильно имена свойство по полям.
Если я работаю с БД.
б) загрузка данных происходит только 1 раз, разные модели представления могут получить доступ к одному поставщику данных, мне не надо каждый раз заботится о всех сопутствующих проблемах.

Как по мне, делать нужно так, как удобно и легко.

судя по вашему описанию, фигня какая-то. удобно только вам
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085379
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman MejtesПо сути Provider'ы, это часть ViewModel'и

какой-то бред
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085380
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttМожно со временем состряпать свой некий bootstrapper

ViPRos
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085382
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttМожно со временем состряпать свой некий bootstrapper

ViPRos

Нет, ВИПРОС это очердной замес на тему вечного двигателя и серебряной пули.

Типа.

А что, если нам заморочиться, и сделать такую волшебную хренобазу, в которой всё при всё создаётся без участия программистов? Сущности? Определяются на уровне данных, клац по кнопке, определил поля -- и готово! А вся при вся бизнес-логика тоже определяется на уровне данных, клац по кнопке, определил некий Workflow -- и готово! Вот сделать это всё и разогнать всех программистов к чёртовой матери. Путь идут пасутся, так как программисты больше не нужны. Нужен лишь один ВИПРОС и талмуд. =)

А начинали подобные движения ещё сопливые немцы в будущей мегакорпорации SAP. И таки добились успехов. При чём не в реализации подобного, а в продажах.

Так что всё впереди, готовьтесь программеры, ваш век подходит к концу
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085386
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttмегакорпорации SAP

мстят за Сталинград
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085629
blest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем спасибо большое за ответы, ясность наступила.
kmaw отдельное спасибо за исправления в схеме.
Я только эту зависимость не понял

kmawRepository зависит от DTO


Если не сложно - каким образом DAL зависит от DTO ?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085667
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blestВсем спасибо большое за ответы, ясность наступила.
kmaw отдельное спасибо за исправления в схеме.
Я только эту зависимость не понял

kmawRepository зависит от DTO


Если не сложно - каким образом DAL зависит от DTO ?

предпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085677
blest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawпредпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили

ну в целом я так и думал. Но в таком случае описывать необходимо каждый репозиторий вручную (имею ввиду генериковое стандартное описание не подойдет) ?!
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085685
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawпредпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили

репо получает и отдаёт Entity, DTO получают/отдают дата-сервисы, иначе репо быстро превратится в God Object и потянет на себя бизнес-логику, чего категорически надо избегать.

у репы банальная, и тупейшая в мире задача -- скрыть от остальной части ПО способ доступа к данным, Entity это у же и есть по сути DTO, только между миром БД и внутренней кухней ПО. зачем городить огород?

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

сервису нафиг не упало получать отмаппленный по все помидоры Entity со всей сотней полей. для чего? ублажить Идею супер-мега-слоёного разделения? в погонях за красивыми картинками и схемками, люди частенько отдаляются от реальности и реальных задач примерно на пару парсеков.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085786
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttрепо получает и отдаёт Entity

такой вариант, наверное, для самых простых справочников "Id Name" годится. так как:
отдаёт
в подавляющем большинстве случаев возвращается join и проекция. да, там уже может быть некоторая логика типа decode (да и сложнее), но это, по-моему, неизбежно (причем, это может быть SQL).
получает
то, что принимается, - это также DTO по сути , даже если это класс Entity - {Id + набор свойств, по которым задается состояние объекта}. все равно придется объект сначала загрузить/создать, установить его состояние, а потом уже сохранить (причем, это может быть SQL).

исходя из вышеперечисленного и следуют мои предпочтения.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085797
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawтакой вариант, наверное, для самых простых справочников "Id Name" годится

глупости какие-то, ты меня не услышал, но я повторю:

задача репо -- скрыть способ доступа к данным от остальной части ПО. репо великим русским языком -- это ХРАНИЛИЩЕ. а хранит он там Entity. соответственно, в задачи репо входит отдавать и принимать Entity, а не какие-то там DTO.

поверх репо пилится дата сервисы (для анемичной модели данных), которые уже принимают и отдают DTO, и ПО работает с дата сервисами. да, Entity в идеале за пределами дата сервисов уже не видна.

резюмирую: не надо сваливать на репо то, чем он не должен заниматься. репо не обязано знать ни о каких DTO, не должно заниматься маппингом и прочим. у него маленькая область ответстенности, и не надо на него сваливать что-то там ещё.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085819
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawтакой вариант, наверное, для самых простых справочников "Id Name" годится

глупости какие-то, ты меня не услышал, но я повторю:

задача репо -- скрыть способ доступа к данным от остальной части ПО. репо великим русским языком -- это ХРАНИЛИЩЕ. а хранит он там Entity. соответственно, в задачи репо входит отдавать и принимать Entity, а не какие-то там DTO.

поверх репо пилится дата сервисы (для анемичной модели данных), которые уже принимают и отдают DTO, и ПО работает с дата сервисами. да, Entity в идеале за пределами дата сервисов уже не видна.

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

т.е. так должен выглядеть репозиторий?

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public void Add(SomeEntity someObject)
        {
            context.SomeObjects.Add(someObject);
        }

public SomeEntity Get(int id)
        {
            return context.SomeObjects.FirstOrDefault(item => item.Id == id);
        }

public IList<SomeEntity> GetAll()
        {
            return context.SomeObjects.ToList();
        }



тогда нафиг он нужен
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085824
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawт.е. так должен выглядеть репозиторий?

да, примерно так.


kmawтогда нафиг он нужен

сколько раз мне ещё сказать про задачи, которые должен решать репозиторий???
в том виде, как ты указал -- он их решает.
такой репозиторий можно замокать для тестов, можно легко подменить способ хранения данных. что ещё нужно-то? зачем в него какую-то логику ещё пихать? зачем эти ваши DTO вообще? разные части ПО могут требовать сотни разных не связанных DTO и связанной с этим логикой. при этом репозиторию накласть на это, он делает своё маленькое дело и в этом его великая ценность.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085829
blest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw,

Как раз описанный Вами вариант репозитория инкапсилирует логику доступа к БД (я потому и задал уточняющий вопрос, т.к. не понял, как DTO вписывается в репозиторий), все join-ы(или include-ы) делаются в датасервисе.

С EF действительно все описание репозитория укладывается в ~60 строчек, но попробуйте написать репозиторий хотя бы для ADO.NET
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085831
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttможно легко подменить способ хранения данных

для такого репо это сделать не получится легко
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085833
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttтакой репозиторий можно замокать для тестов

мой вариант тоже без проблем мокается
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085834
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttзачем в него какую-то логику ещё пихать?

джоины и decode-логику куда пихать?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085835
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttразные части ПО могут требовать сотни разных не связанных DTO

это сильно абстрактно. если что-то эдакое потребуется, может вообще потребоваться много чего переписать
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085836
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blestвсе join-ы(или include-ы) делаются в датасервисе

я не испытываю прям органической неприязни к такому варианту, но тут, на мой взгляд, теряется сама надобность репозитория. тогда сам ОРМ можно считать репозиторием.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085837
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
все-равно, как не крути, есть "доменная логика". и в сервис её нормально не впихнешь.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085839
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blestвсе join-ы(или include-ы) делаются в датасервисе

т.е. вариант с реализацией на нативном SQL отпадает
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085843
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blestС EF ... для ADO.NET

в ADO.NET нет Entity. там есть только SQL и DTO. и там, наверное много логики в БД. но если надо феншуй - то легко: репо работают с DTO
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085845
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawblestС EF ... для ADO.NET

в ADO.NET нет Entity. там есть только SQL и DTO. и там, наверное много логики в БД. но если надо феншуй - то легко: репо работают с DTO

а захочется NHibernate - тоже без проблем, из датасервиса не надо будет выпиливать всякие останки от контекста, которые туда вместе с "все join-ы(или include-ы) делаются в датасервисе".
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085847
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawkmawпропущено...


в ADO.NET нет Entity. там есть только SQL и DTO. и там, наверное много логики в БД. но если надо феншуй - то легко: репо работают с DTO

а захочется NHibernate - тоже без проблем, из датасервиса не надо будет выпиливать всякие останки от контекста, которые туда вместе с "все join-ы(или include-ы) делаются в датасервисе".

хотя не пробовал, там с транзакциями наверное так сразу не получится
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085862
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawдля такого репо это сделать не получится легко

серебряной пули не существует. но можешь поверить мне на слово, я подобный репо переводил с NHibernate на EF, и благодаря тому, что все обращения к БД делались исключительно через репо, а не через ISession, я это сделал за 1 день, при количестве Entity 100+

kmawмой вариант тоже без проблем мокается

не правда, ты в репо инкапсулируешь кроме работу с Entity ещё и работу с DTO, так что не получится замокать только хранилище (например, подменить EF или NH на коллекции в памяти), не трогая ни один байт кода, работающий с DTO.

kmawджоины и decode-логику куда пихать?

в дата-сервисы. а если точнее, в механику проекций. ты как DTO из Entity получаешь? я исключительно 100% проекциями, и никак иначе.

kmawэто сильно абстрактно. если что-то эдакое потребуется, может вообще потребоваться много чего переписать

достаточно того, что это абстрактно, а что касается «эдакого» — это можно о чём угодно сказать.

kmawвсе-равно, как не крути, есть "доменная логика". и в сервис её нормально не впихнешь.

ты говоришь о анемичной модели (дата-сервисы, DTO), и о доменной логике в таком случае говорить не приходится. логику ты можешь пихнуть хоть в сервисы, хоть уровнем выше, но суть в том, что ты работаешь с кортежами данных. никакой доменной моделью тут даже и не пахнет (если брать картинки, которые в начале топике опубликованы).
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085863
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blestно попробуйте написать репозиторий хотя бы для ADO.NETА что в этом сложного?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085864
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAblestно попробуйте написать репозиторий хотя бы для ADO.NETА что в этом сложного?

надо будет состряпать ORM. чтобы сильно не возится, можно дёрнуть исходники EF или NH
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085866
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DTO, Entity... Да у вас, парни, EF головного мозга :)

Репозиторий может внутри себя использовать стратегию доступа к стороннему сервису, или даже сотне сервисов с разным API и форматом возвращаемых данных.

Вот и подумайте, где у вас DTO, а где Entity :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085867
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttне правда, ты в репо инкапсулируешь кроме работу с Entity ещё и работу с DTO, так что не получится замокать только хранилище (например, подменить EF или NH на коллекции в памяти), не трогая ни один байт кода, работающий с DTO

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
[TestMethod]
        public void Save_WhenMoreMaxLengthNameAndShortName_ThrowDataServiceException()
        {
            int factLength = 71;
            int maxLength = 70;
            InfoSystemDTO s = new InfoSystemDTO()
            {
                Name = new String('9', factLength),
                ShortName = new String('9', factLength)
            };

            try
            {
                service.Save(userId, s);
            }
            catch (DataServiceException ex)
            {
                Assert.AreEqual<int>(2, ex.Messages.Count, "Должно быть 2 сообщения об ошибке - по одному для каждого поля");
                

                Assert.AreEqual<bool>(true, ex.Messages.ContainsKey("Name"), "Должно быть сообщение об ошибке поля Name");
                Assert.AreEqual<bool>(true, ex.Messages.ContainsKey("ShortName"), "Должно быть сообщение об ошибке поля ShortName");

                Assert.AreEqual<string>(String.Format(MessageConst.LengthMaxConstraintMsg, factLength, maxLength), ex.Messages["Name"][0],
                    String.Format("Сообщение об ошибке для поля Name должно быть \"{0}\"", MessageConst.EmptyConstraintMsg));
                Assert.AreEqual<string>(String.Format(MessageConst.LengthMaxConstraintMsg, factLength, maxLength), ex.Messages["ShortName"][0],
                    String.Format("Сообщение об ошибке для поля ShortName должно быть \"{0}\"", MessageConst.EmptyConstraintMsg));
                return;
            }

            Assert.Fail("Метод не бросил DataServiceException");

        }
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085869
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAпропущено...
А что в этом сложного?

надо будет состряпать ORM. чтобы сильно не возится, можно дёрнуть исходники EF или NH Чтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085870
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
public InfoSystemServiceUnitTest()
        {
            IInfoSystemAccessService infoSystemAccessService = new InfoSystemAccessService(
                Mock.Of<IUserRepository>(d => d.GetById(userId) == new UserDTO() { }), 
                Mock.Of<IInfoSystemAccessSpecification>(d => d.GetListInfoSystemIdForDirectManager(userId) == new List<long>()  &&
                                                        d.GetListInfoSystemIdForProjectManager(userId) == new List<long>()      &&
                                                        d.GetListInfoSystemTypeIdForDirectManager(userId) == new List<long>()   &&
                                                        d.GetListInfoSystemTypeIdForProjectManager(userId) == new List<long>()));

            
            service = new InfoSystemService(
                    null,
                    Mock.Of<IInfoSystemRepository>(d => d.Save(userId, new InfoSystemDTO() { }) == new InfoSystemDTO() { }),
                    Mock.Of<IInfoSystemTypeRepository>(d => d.GetList(userId, null) == new List<InfoSystemTypeDTO>() 
                    { 
                       new  InfoSystemTypeDTO()
                       {
                         Id = 100000,
                         Name = "Тип1"
                       },
                       new  InfoSystemTypeDTO()
                       {
                         Id = 100001,
                         Name = "Тип2"
                       }
                    }),
                    null,
                    infoSystemAccessService);

        }
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085877
blest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttпропущено...


надо будет состряпать ORM. чтобы сильно не возится, можно дёрнуть исходники EF или NH Чтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно.

Да, IDataReader будет достаточно, просто это уже не 60 строчек кода будет.
Я к тому, что репозиторий на то и нужен, чтобы именно эту реализацию доступа к БД в себе и заключать и ничего лишнего имхо.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085879
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAможно тупо IDataRecord в то, что тебе нужно отобразить

в DTO
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085880
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw
Код: c#
1.
service.Save(userId, s);



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


kmaw
Код: c#
1.
Mock.Of<IUserRepository>(d => d.GetById(userId) == new UserDTO() { })



Эмм... как я и говорил, ты не можешь замокать хранилище, ты мокаешь фабрику DTO, и это вообще не имеет никакого отношения к хранилищу. Вообще.

С нормальным репо, я могу сделать один мок на всё хранилище, а дальше уже тестировать сервисы, тестировать проекции и прочее.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085884
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAЧтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно.

Тогды прощай навигации )) ну да, в принципе можно, и это будет не много кода.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085886
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANADTO, Entity... Да у вас, парни, EF головного мозга :)

Репозиторий может внутри себя использовать стратегию доступа к стороннему сервису, или даже сотне сервисов с разным API и форматом возвращаемых данных.

Вот и подумайте, где у вас DTO, а где Entity :)

Я об этом и говорю. Репо это по факту «ДАЙ-ПОЛОЖИ». Откуда он чего берёт и куда кладёт, нам фиолетово. Часть сущностей может лежать в SQL, часть в монго, часть вообще через веб-сервисы. И нам всё равно это всё фиолетово.

Просто под DTO понимаются кортежи данных, нужных бизнесу. Типа мне надо на форму вывести 10 полей, или в грид собрать кортежи по 10 полей, нафига мне не упало всё остальное, для этого используются DTO.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085887
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAможно тупо IDataRecord в то, что тебе нужно отобразить

в DTOЕсли Вам надо в DTO, отображайте в DTO :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085888
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttи это вообще не имеет никакого отношения к хранилищу. Вообще

естественно не имеет. и не должно. это тест бизнес-логики
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085890
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


в DTOЕсли Вам надо в DTO, отображайте в DTO :)

Он не понимает, что Entity это уже и есть DTO, только в контексте репо. На репо он накидывает лопатой лишнюю ответственность. Ну его право конечно, но это неправильно.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085891
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


в DTOЕсли Вам надо в DTO, отображайте в DTO :)

давай(те) на ты. а во что это еще можно отобразить?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085893
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttи это вообще не имеет никакого отношения к хранилищу. Вообще

естественно не имеет. и не должно. это тест бизнес-логики

Ну так ты мочишь тут не репо, а уже бизнес-логику. А выглядит, как будто мочишь репо, хотя это не верно. Зачем создавать путанницу намерянно, я не понимать. Видимо это особый случай садо-мазохизма.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085894
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAЧтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно.

Тогды прощай навигации )) ну да, в принципе можно, и это будет не много кода.Указанный выше контракт и не предполагает никакой навигации. Да и какая в общем случае от неё польза? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085895
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttПросто под DTO понимаются кортежи данных, нужных бизнесу

ну, это если сильно концептуально. так-то Entity - это материал для ОРМ
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085896
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Если Вам надо в DTO, отображайте в DTO :)

давай(те) на ты. а во что это еще можно отобразить?Ну к примеру можно отобразить классически: в модель области определения
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085897
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawпропущено...


естественно не имеет. и не должно. это тест бизнес-логики

Ну так ты мочишь тут не репо, а уже бизнес-логику. А выглядит, как будто мочишь репо, хотя это не верно. Зачем создавать путанницу намерянно, я не понимать. Видимо это особый случай садо-мазохизма.

где тут я мочу бизнес-логику?

Код: c#
1.
2.
3.
4.
5.
6.
 IInfoSystemAccessService infoSystemAccessService = new InfoSystemAccessService(
                Mock.Of<IUserRepository>(d => d.GetById(userId) == new UserDTO() { }), 
                Mock.Of<IInfoSystemAccessSpecification>(d => d.GetListInfoSystemIdForDirectManager(userId) == new List<long>()  &&
                                                        d.GetListInfoSystemIdForProjectManager(userId) == new List<long>()      &&
                                                        d.GetListInfoSystemTypeIdForDirectManager(userId) == new List<long>()   &&
                                                        d.GetListInfoSystemTypeIdForProjectManager(userId) == new List<long>()));



AccessSpecification - это уровень репозитория
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085898
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAмодель области определения

это что еще за область?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085899
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAмодель области определения

это что еще за область?Domain Model, так понятнее?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085900
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


это что еще за область?Domain Model, так понятнее?

при использовании IDataReader - это все DTO, не более.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085901
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttПросто под DTO понимаются кортежи данных, нужных бизнесу

ну, это если сильно концептуально. так-то Entity - это материал для ОРМКонцептуально ORM решает задачу преобразования объекта реального мира в форму, пригодную для сохранения в реляционной базе данных.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085902
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANADomain Model

их просто там нет
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085904
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Domain Model, так понятнее?

при использовании IDataReader - это все DTO, не более.Вообще-то Domain Model Object и DTO не одно и тоже.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085906
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANADomain Model

их просто там нетГде там? В Вашей программе?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085907
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


ну, это если сильно концептуально. так-то Entity - это материал для ОРМКонцептуально ORM решает задачу преобразования объекта реального мира в форму, пригодную для сохранения в реляционной базе данных.

ORM решает более земную задачу - Entity <-> БД
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085908
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Концептуально ORM решает задачу преобразования объекта реального мира в форму, пригодную для сохранения в реляционной базе данных.

ORM решает более земную задачу - Entity <-> БДДайте определение Entity.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085909
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


при использовании IDataReader - это все DTO, не более.Вообще-то Domain Model Object и DTO не одно и тоже .

а я разве обратное утверждаю?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085910
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


ORM решает более земную задачу - Entity <-> БДДайте определение Entity.

ок. это отображенная в ООП-класс таблица БД
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085911
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAУказанный выше контракт и не предполагает никакой навигации. Да и какая в общем случае от неё польза? :)

Удобно для корня агрегации, иначе придётся собирать агрегат по кусочкам.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085912
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Дайте определение Entity.

ок. это отображенная в ООП-класс таблица БДХорошо.
Пример: есть класс Person , что содержит следующий список полей: имя, список адресов и список телефонов.

Как его отобразить в одну таблицу БД?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085913
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawгде тут я мочу бизнес-логику?

вот:

kmaw
Код: c#
1.
Mock.Of<IUserRepository>(d => d.GetById(userId) == new UserDTO() { }),



репозиторий должен хранить Entity юзера (.NET представление его аналога в хранилище, т.е. по сути табличный кортеж), а UserDTO это некий срез данных, нужный сервису, UserDTO полностью абстрагируется от того, как данные лежат в хранилище, в UserDTO могут быть намапленные данные из других таблиц, например, адрес, лежащий в отдельной таблице технически, т.е. это уровень выше репы.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085915
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAУказанный выше контракт и не предполагает никакой навигации. Да и какая в общем случае от неё польза? :)

Удобно для корня агрегации, иначе придётся собирать агрегат по кусочкам.Не понял, почему по кусочкам?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085918
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttпропущено...


Удобно для корня агрегации, иначе придётся собирать агрегат по кусочкам.Не понял, почему по кусочкам?

Из твоего примера выше:

Person.Adresses

без навигаций, придётся дополнительно дёргать адреса
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085924
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот примеры DTO для User-а:

UserLoginDTO
UserProfileDTO
UserActivityDTO

и т.д. в хранилище это как-то лежит в разных таблицах, корень аггрегации -- User, одна сущность, а DTO -- много, в зависимости от задач. нафига на каждый чих тащить всё в одном DTO, мне не понятно.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085926
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawгде тут я мочу бизнес-логику?

вот:

kmaw
Код: c#
1.
Mock.Of<IUserRepository>(d => d.GetById(userId) == new UserDTO() { }),




репозиторий должен хранить Entity юзера (.NET представление его аналога в хранилище, т.е. по сути табличный кортеж), а UserDTO это некий срез данных, нужный сервису, UserDTO п олностью абстрагируется от того, как данные лежат в хранилище , в UserDTO могут быть намапленные данные из других таблиц , например, адрес, лежащий в отдельной таблице технически, т.е. это уровень выше репы.

естественно. просто тот репо который ты предлагаешь, это обертка над linq. у меня это полное скрытие
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085927
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


ок. это отображенная в ООП-класс таблица БДХорошо.
Пример: есть класс Person , что содержит следующий список полей: имя, список адресов и список телефонов.

Как его отобразить в одну таблицу БД?

если список телефонов (он же не 1000000 записей), это коллекция которая мапится вместе с Person
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085929
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Хорошо.
Пример: есть класс Person , что содержит следующий список полей: имя, список адресов и список телефонов.

Как его отобразить в одну таблицу БД?

если список телефонов (он же не 1000000 записей), это коллекция которая мапится вместе с PersonКуда маппится, в туже таблицу БД? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085930
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttи т.д. в хранилище это как-то лежит в разных таблицах

а вот это не 100%. у DTO уже нет взаимнооднозначного отображения. DTO - это композит, там и count-ы могут лежать, и вообще дополнительные вычисленные данные
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085932
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


если список телефонов (он же не 1000000 записей), это коллекция которая мапится вместе с PersonКуда маппится, в туже таблицу БД? :)

в другую. skyANA, зачем такие вопросы задаешь?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085934
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Куда маппится, в туже таблицу БД? :)

в другую. skyANA, зачем такие вопросы задаешь?Да у вас тут терминология не пойми какая.

У Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085936
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAДа у вас тут терминология не пойми какая

там в начале топика схема. я понимаю Entity только как материал для ОРМ, утилитарные классы. нет ОРМ - нет Entity. а DTO всегда есть.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085937
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
не путать Entity-классы с сущностями в БД
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085939
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAДа у вас тут терминология не пойми какая

там в начале топика схема. я понимаю Entity только как материал для ОРМ, утилитарные классы. нет ОРМ - нет Entity. а DTO всегда есть.Значит нам с тобой не по пути :) Для меня entity - это сущность, самостоятельная логическая единица, что не сводится к набору атрибутов, а характеризуется непрерывностью и индивидуальностью существования. :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085941
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAа характеризуется непрерывностью и индивидуальностью существования

вот такой она и лежит записями в таблицах в реляционной БД
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085943
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAа характеризуется непрерывностью и индивидуальностью существования

вот такой она и лежит записями в таблицах в реляционной БД

а в ОРМ-ах - просто рабочая лошадка
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085945
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAа характеризуется непрерывностью и индивидуальностью существования

вот такой она и лежит записями в таблицах в реляционной БДПри чём тут реляционная БД? Нет её. :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085946
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


вот такой она и лежит записями в таблицах в реляционной БДПри чём тут реляционная БД? Нет её. :)

тогда и Entity нет. с сервисов приходит не энтити
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085947
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
При чём тут реляционная БД? Нет её. :)

тогда и Entity нет. с сервисов приходит не энтитивот я и говорю, что нам не по пути :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085948
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
При чём тут реляционная БД? Нет её. :)

тогда и Entity нет. с сервисов приходит не энтити

во всяких монго тоже лежат не энтити
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085949
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawтогда и Entity нет. с сервисов приходит не энтити
это пять!
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085951
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


тогда и Entity нет. с сервисов приходит не энтитивот я и говорю, что нам не по пути :)

skyANA, выдай свою мыслю, как надо
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085953
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилkmawтогда и Entity нет. с сервисов приходит не энтити
это пять!

шесть. мое определение Entity выше видел?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085954
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawkmawпропущено...


тогда и Entity нет. с сервисов приходит не энтити

во всяких монго тоже лежат не энтитиИсходя из твоего определения, да. Исходя из моего - наоборот.
Хотя "во всяких монго" можно целиком агрегаты хранить, это да.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085956
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
вот я и говорю, что нам не по пути :)

skyANA, выдай свою мыслю, как надоЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085960
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


skyANA, выдай свою мыслю, как надоЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root.

молодец. а в контексте топика?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085962
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root.

Вот-вот. Проблемы возникают тогда, когда ORM-овские Entity пытаются подогнать под DDD. Этим страдают даже в Microsoft.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085963
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root.

Вот-вот. Проблемы возникают тогда, когда ORM-овские Entity пытаются подогнать под DDD. Этим страдают даже в Microsoft.

это высказывание не понял
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085967
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAУ Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :)

У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085969
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttпропущено...


Вот-вот. Проблемы возникают тогда, когда ORM-овские Entity пытаются подогнать под DDD. Этим страдают даже в Microsoft.

это высказывание не понял

Погугли DDD EF или DDD NHibernate и поймёшь, и обнаружишь тонны тупикового маразма.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085970
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAУ Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :)

У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того.

это все так. а если нет ОРМ?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085971
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttБлагодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты

это не благодаря, а потому что так надо для ОРМ
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085972
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttUOW

его может не быть. я думаю, что нет ОРМ, нет и его
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085974
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttпропущено...


У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того.

это все так. а если нет ОРМ?

если ты не используешь чужую ORM, значит изобретёшь свою, при чём не важно как-то её назовешь, даже так:

INoOrmDbContext...

всё равно будет ORM, как не крути :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085976
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttБлагодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты

это не благодаря, а потому что так надо для ОРМ

вовсе нет. есть ORM, которые лишены таких возможностей под корень.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085978
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttUOW

его может не быть. я думаю, что нет ОРМ, нет и его

да много чего может не быть.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085979
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttINoOrmDbContext
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085980
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttINoOrmDbContext
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085982
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Я следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root.

молодец. а в контексте топика?В контексте топика скажу, что репозиторий по определению должен возвращать Domain Model Objects, которыми оперирует слой бизнес-логики, а не DTO.
На уровне Web-сайтов и WPF приложения появляются модели представления.

Но данной схемы не обязательно придерживаться всегда, надо смотреть на конкретную задачу.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085984
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttUOW

его может не быть. я думаю, что нет ОРМ, нет и егоНу ну... Я уже давно не использую DataSet, но это таки пример реализации UoW :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085986
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAУ Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :)

У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того.Вот опять своя доморощенная терминология :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085987
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот что сюда надо закинуть: микросервисы
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085990
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а мне нравится db-repo-model-services
и дальше вьюмодельки для гуя и дтошки для микросервисов. Для меня вьюмоделька это по сути дтошка, только у дтошки "гуй" - это сервис какой-нибудь, а для вьюмодельки "гуй" это, например, винформз.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085992
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAВот опять своя доморощенная терминология :)

Какая ещё доморощенная терминология?

В EF/NH данные отражаются в классы, которые они называют Entity. Это отнюдь не Entity из мира DDD, хоть и местами похожи, хоть и отдельные товарищи пытаются с помощью лома и такой-то матери туда втулить. Ну не получается.

И как эти классы называть? POCO?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085993
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttВ EF/NH данные отражаются в классы, которые они называют Entity

алилуя
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085995
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAВот опять своя доморощенная терминология :)

Какая ещё доморощенная терминология?

В EF/NH данные отражаются в классы, которые они называют Entity.
Код: c#
1.
2.
3.
4.
5.
6.
public class User
{
    public virtual int Id { get; set; }
    public virtual string Name { get; set; }
    public virtual IList<Phone> EmergencyPhones { get; set; }
}


Это Entity ? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085996
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAВот что сюда надо закинуть: микросервисы

Зачем?

авторУправление несогласованностями подобным образом — новый вызов для многих команд разработки, но это часто соответствует практикам бизнеса.

Больше вызовов! Больше!
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085997
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttВ EF/NH данные отражаются в классы, которые они называют Entity

алилуяТот же вопрос: 18323769 .
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39085999
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA
Код: c#
1.
2.
3.
4.
5.
6.
public class User
{
    public virtual int Id { get; set; }
    public virtual string Name { get; set; }
    public virtual IList<Phone> EmergencyPhones { get; set; }
}



Это Entity ? :)

Да. (вот только virtual для атрибутов, это зло, сразу видно что это в угоду NH)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086003
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANA
Код: c#
1.
2.
3.
4.
5.
6.
public class User
{
    public virtual int Id { get; set; }
    public virtual string Name { get; set; }
    public virtual IList<Phone> EmergencyPhones { get; set; }
}



Это Entity ? :)

Да.cool
hVosttвот только virtual для атрибутов, это злоА в чём зло?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086005
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ещё нужно выяснить у камрада kmaw почему объект класса User не может существовать без реляционной БД и ORM.
И почему не может в таком виде как есть храниться в MongoDB :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086007
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttвот только virtual для атрибутов, это злоА в чём зло?

Потому что в угоду NH, ему нужно, чтобы он работал. А это всего лишь поле с данными, EF прекрасно работает без virtual, а в NH намудили (потому что NH -- УГ), вот и страдайте.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086010
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мне думается термин дто вообще надо выкинуть из топика. Дто это вообще не про логику, не про модель, не про репозитории. Там другие названия есть.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086011
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttпропущено...


Какая ещё доморощенная терминология?

В EF/NH данные отражаются в классы, которые они называют Entity.
Код: c#
1.
2.
3.
4.
5.
6.
public class User
{
    public virtual int Id { get; set; }
    public virtual string Name { get; set; }
    public virtual IList<Phone> EmergencyPhones { get; set; }
}



Это Entity ? :)

если для ОРМ, то да. потому что их может быть похожих несколько, и они != сущностям БД
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086013
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttПотому что в угоду NH, ему нужно, чтобы он работал

это нормально. потому что - это Entity
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086016
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAпропущено...
А в чём зло?

Потому что в угоду NH, ему нужно, чтобы он работал. А это всего лишь поле с данными, EF прекрасно работает без virtual, а в NH намудили (потому что NH -- УГ), вот и страдайте. Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий.

Таки в чём зло? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086017
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.мне думается термин дто вообще надо выкинуть из топика. Дто это вообще не про логику, не про модель, не про репозитории. Там другие названия есть.

Не надо выкидывать. DTO прекрасно работает с анемичной моделью, т.е. у нас есть дата-сервисы, и мы взаимодействуем с ними с помощью DTO. Например CRUD-сервисы можно сделать базовыми и они будут работать сразу для всех существующих таблиц в БД. А затем запиливать дополнительную логику в сервисах. Это стандартный путь для большинства энтерпрайзов.

Вот только DDD здесь не пахнет, а это другая архитектура и гораздо меньше подходит для CRUD-базед систем.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086020
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttпропущено...


Потому что в угоду NH, ему нужно, чтобы он работал. А это всего лишь поле с данными, EF прекрасно работает без virtual, а в NH намудили (потому что NH -- УГ), вот и страдайте. Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий.

Таки в чём зло? :)

хвост ненавидит хибернейт. а ненависть - это зло
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086022
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий.

Таки в чём зло? :)

Эти классы -- не POCO. Какие ещё аргументы нужны? Для virtual полей допустимо иметь в классе 2 значения: заданное, и прокси-значение. Это не просто зло, это ахтунг полнейший.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086024
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий.

Таки в чём зло? :)

хвост ненавидит хибернейт. а ненависть - это злоТы это от ответа не увиливай: 18323802 :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086026
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawхвост ненавидит хибернейт. а ненависть - это зло

Я не ненавижу, я его презираю. Он своё отжил. Да, было время, когда EF был кособокий и кривой. Но щас пора брать лопату и закапывать NH глубоко.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086028
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANA Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий.

Таки в чём зло? :)

Эти классы -- не POCO. Какие ещё аргументы нужны?Как какие? Доказывающие то, что это причиняет кому-либо вред, ущерб, страдания :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086030
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawхвост ненавидит хибернейт. а ненависть - это зло

Я не ненавижу, я его презираю. Он своё отжил. Да, было время, когда EF был кособокий и кривой. Но щас пора брать лопату и закапывать NH глубоко.Да, пора переходить на Dapper и микросервисы :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086031
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAЕщё нужно выяснить у камрада kmaw почему объект класса User не может существовать без реляционной БД и ORM.
И почему не может в таком виде как есть храниться в MongoDB :)

так я от ответа и не увиливаю. это опять DTO. еще раз: нет ОРМ - нет Entity
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086032
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

DTO - УГ, потому, что нет однозначной Логики отображения ДТО на Модель
В ВИПРОС есть Частичное представление Макротипа с четкой логикой отображения
ВИПРОС может автоматически сгенерировать всевозможные Частичные представления макротипа (но лучше все ж создать по отдельности, так как всевозможных генерируется дофига :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086033
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAКак какие? Доказывающие то, что это причиняет кому-либо вред, ущерб, страдания :)

Хм. А если бы NH требовал, чтобы любые примитивные значения можно было определять только через специальные обёртки?

Код: c#
1.
2.
3.
4.
5.
6.
public class User
{
    public virtual Int32NhValue Id { get; set; }
    public virtual StringNhValue Name { get; set; }
    public virtual IList<Phone> EmergencyPhones { get; set; }
}



норм?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086034
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawнет ОРМ - нет Entity

Не верный ответ.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086035
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи
остальная мишура - технические костыли
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086036
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAДа, пора переходить на Dapper и микросервисы :)

Совсем? EF 7 смотрел?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086037
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosDTO - УГ, потому, что нет однозначной Логики отображения ДТО на Модель

Есть. Это конфигурация проекции.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086038
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw,

надо сначала определиться - что такое ентити и нафига ему ОРМ какой то
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086039
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

по моему пониманию дто работает прекрасно с любой моделью в любом виде. Так как это по сути просто контракт сервиса "в последней инстанции". Данные обрабатываются логикой в любом виде и экспозятся через сервисы куда угодно. Но то что "с той стороны" сервисов - уже не релевантно по сути к вопросу доступа к данным и их обработке. А, как я понимаю, именно это тут и обсуждается в первую очередь. То есть я считаю что дто это передача данных во внешнюю подсистему\систему. Даже если она живет в том же процессе, если мы сказали дто, значит данные пошли в другой домен.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086040
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoshVostt,

ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи
остальная мишура - технические костыли

Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA).
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086041
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosчто такое ентити

Ентити определяется идентификатором (Id, Uid, Guid...). Два объекта с одинаковым идентификатором считаются равными, без сравнения их содержимого. Это Entity.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086042
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRosDTO - УГ, потому, что нет однозначной Логики отображения ДТО на Модель

Есть. Это конфигурация проекции.
покажи пример (Проекция - это метаданные, подмножество метаданных макротипа. Не всегда возможно Проекция, так как Проекция накладывает доп ограничения на целостность макротипа - нужны значения по умолчанию как минимум, если например, Проекция редактируема и т.д.)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086043
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.А, как я понимаю, именно это тут и обсуждается в первую очередь

это Вам и мне понятно.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086044
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

значит ентити ваш - Объект с лайфтаймом (коллекция)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086047
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRoshVostt,

ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи
остальная мишура - технические костыли

Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA).

это про проекции был вопрос, при чем тут слой презентации
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086048
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRoshVostt,

ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи
остальная мишура - технические костыли

Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA).
Частичное представление - это Точка зрение на Модель определенной Роли (Актора)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086049
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"нет ОРМ - нет Entity"
=нет объектно реляционного мапера - нет энтити
если мы натравливаем ef не на базу, а на xml файл, не меняя код, просто меняя источник данных, энтити исчезают?
Таким образом невозможно знать есть энтити или нет, не видя connectionstring, так выходит?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086052
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.,

ОРМ разные, есть например расшифровка - Объект Роле Моделинг
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086053
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoshVosttпропущено...


Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA).
Частичное представление - это Точка зрение на Модель определенной Роли (Актора)

в контексте тоgика - джоин проекция и where. которые хвост хочет видеть в датасервисах
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086054
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.если мы натравливаем ef не на базу, а на xml файл, не меняя код, просто меняя источник данных, энтити исчезают?

для терминологической чистоты - да
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086055
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosпокажи пример (Проекция - это метаданные, подмножество метаданных макротипа. Не всегда возможно Проекция, так как Проекция накладывает доп ограничения на целостность макротипа - нужны значения по умолчанию как минимум, если например, Проекция редактируема и т.д.)

Код: c#
1.
2.
CreateMap<Persona, PersonaListItemDto>()
   .ForMember(m => m.LikesCount, a => a.PersonaLikes.Count(p => p.IsModerated));
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086056
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosзначит ентити ваш - Объект с лайфтаймом (коллекция)

Это что угодно с идентификатором.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086057
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawэто про проекции был вопрос, при чем тут слой презентации

Слово «представление» прозвучало.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086058
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRosпокажи пример (Проекция - это метаданные, подмножество метаданных макротипа. Не всегда возможно Проекция, так как Проекция накладывает доп ограничения на целостность макротипа - нужны значения по умолчанию как минимум, если например, Проекция редактируема и т.д.)

Код: c#
1.
2.
CreateMap<Persona, PersonaListItemDto>()
   .ForMember(m => m.LikesCount, a => a.PersonaLikes.Count(p => p.IsModerated));



и где это должно находиться? правильно - в репозитории
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086060
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw,

давно пора этот "контекст" выбросить
ОРМ в смысле Объект Релейшн Маппинг - узкая тема и о не й по хорошему воще ничего не должно быть известно программисту, так глубоко это техническое решение должно прятаться
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086061
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosЧастичное представление - это Точка зрение на Модель определенной Роли (Актора)

Ээмм.. кортеж -- чем не подходит?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086062
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

кортеж не содержит в себе информациь - откуда он есть пошло и кому чего должен
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086063
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosи о не й по хорошему воще ничего не должно быть известно программисту

оно и так глубоко, рядом с репозиториями и Entity
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086064
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAЕщё нужно выяснить у камрада kmaw почему объект класса User не может существовать без реляционной БД и ORM.
И почему не может в таком виде как есть храниться в MongoDB :)

так я от ответа и не увиливаю. это опять DTO. еще раз: нет ОРМ - нет Entityno comments
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086066
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw,

если бы блыло глубок то никаких разговоров кроме "ентити" не должно было быть
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086067
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawи где это должно находиться? правильно - в репозитории

репозитарий тут при чём? репозитарию фиолетово на бизнес-логику, чё и кому нужно. он предоставляет доступ в хранилище, а что конкретно ты будешь из него брать и как с этим работать -- не его дело, поэтому ни про какие DTO ему знать не надо, иначе пухнет ответственность. репозиторий вообще может использоваться в разных модулях и даже приложения, один репозиторий -- куча клиентов. и чё теперь, ему для всех надо кучу DTO хранить? идиотизм высшей пробы.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086068
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoshVostt,

кортеж не содержит в себе информациь - откуда он есть пошло и кому чего должен

именно! затем он и полезен, что это чистый кортеж, без меты и логики.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086069
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAКак какие? Доказывающие то, что это причиняет кому-либо вред, ущерб, страдания :)

Хм. А если бы NH требовал, чтобы любые примитивные значения можно было определять только через специальные обёртки?

Код: c#
1.
2.
3.
4.
5.
6.
public class User
{
    public virtual Int32NhValue Id { get; set; }
    public virtual StringNhValue Name { get; set; }
    public virtual IList<Phone> EmergencyPhones { get; set; }
}



норм?
Тогда бы можно было говорить о намеренном причинении страданий :) Но такого нет, значит и зла нет.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086070
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRoskmaw,

если бы блыло глубок то никаких разговоров кроме "ентити" не должно было быть

это потому что, не только лишь все могут его спрятать в DAL, и говорят, что это нормально. я считаю, что это не нормально
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086072
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAДа, пора переходить на Dapper и микросервисы :)

Совсем? EF 7 смотрел?Не смотрел. А что там смотреть-то?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086073
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAТогда бы можно было говорить о намеренном причинении страданий :) Но такого нет, значит и зла нет.

о как. а теперь факт:

Код: c#
1.
2.
3.
4.
5.
6.
public class SomeEntity
{
    private int _id;
    public virtual Id { get { return _id; } set { _id = value; } }
    ...
}



как думаешь, может ли быть такая ситуция с NHibernate, когда _id == 1, а Id == 0 ?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086074
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttрепозитарию фиолетово на бизнес-логику

ему и так на неё фиолетово.
моделируем ситуацию, что-то хранится в JS. и что, передавать/возвращать в репозиторий JS, ведь там хранится JS?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086075
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAНе смотрел. А что там смотреть-то?

Зря. Смотри как развивается, поддержку NoSQL смотри
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086077
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.hVostt,

по моему пониманию дто работает прекрасно с любой моделью в любом виде. Так как это по сути просто контракт сервиса "в последней инстанции". Данные обрабатываются логикой в любом виде и экспозятся через сервисы куда угодно. Но то что "с той стороны" сервисов - уже не релевантно по сути к вопросу доступа к данным и их обработке. А, как я понимаю, именно это тут и обсуждается в первую очередь. То есть я считаю что дто это передача данных во внешнюю подсистему\систему. Даже если она живет в том же процессе, если мы сказали дто, значит данные пошли в другой домен.Вы практически дали классическое определение понятию DTO.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086078
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttрепозитарию фиолетово на бизнес-логику

ему и так на неё фиолетово.
моделируем ситуацию, что-то хранится в JS. и что, передавать/возвращать в репозиторий JS, ведь там хранится JS?

ему не фиолетово, он должен знать какие DTO кому нужны.

ну или тебе заняться больше в этой жизни нечем и ты продублировал для каждого Entity по DTO. молодец чё сказать. я был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086079
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRoshVostt,

кортеж не содержит в себе информациь - откуда он есть пошло и кому чего должен

именно! затем он и полезен, что это чистый кортеж, без меты и логики.
да ничем он не полезен (кроме тех случаев, когда модель в башке прогера и в коде размазан)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086080
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAТогда бы можно было говорить о намеренном причинении страданий :) Но такого нет, значит и зла нет.

о как. а теперь факт:

Код: c#
1.
2.
3.
4.
5.
6.
public class SomeEntity
{
    private int _id;
    public virtual Id { get { return _id; } set { _id = value; } }
    ...
}




как думаешь, может ли быть такая ситуция с NHibernate, когда _id == 1, а Id == 0 ?

ты про прокси? там там могут быть и другие страдания
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086081
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttя был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел

а что такого беспредельного? зато архитектурная ясность.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086082
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawты про прокси? там там могут быть и другие страдания

я прокси только приемлю для Lazy-load, но никак не для чухни типа отслеживания изменений.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086083
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRosчто такое ентити

Ентити определяется идентификатором (Id, Uid, Guid...). Два объекта с одинаковым идентификатором считаются равными, без сравнения их содержимого. Это Entity.Тут надо уточнить, что идентификация может быть и естественной.
Даже скажу так: от неё и надо плясать.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086084
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttя был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел

а что такого беспредельного? зато архитектурная ясность.

никакой ясности, бесполезное дублирование. что за маниакальная страсть -- скрыть Entity? есть хоть какие-то предпосылки для подобной деятельности?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086085
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawты про прокси? там там могут быть и другие страдания

я прокси только приемлю для Lazy-load, но никак не для чухни типа отслеживания изменений.

это гибкая весчь. скоро и в EF так будет
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086086
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawэто гибкая весчь. скоро и в EF так будет

В EF уже сто лет так. И лейзи есть, и отслеживание изменений. И полная поддержка POCO, чего хиберу не снилось.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086087
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttбесполезное дублирование

ТС, кстати, тоже вложил этот посыл
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086088
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawэто гибкая весчь. скоро и в EF так будет

В EF уже сто лет так. И лейзи есть, и отслеживание изменений. И полная поддержка POCO, чего хиберу не снилось.
Еще бы коллекции прятать. Хотя бы за IEnumerable
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086090
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttViPRosзначит ентити ваш - Объект с лайфтаймом (коллекция)

Это что угодно с идентификатором.Я б всё таки сказал, что обладает уникальностью.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086092
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.hVosttпропущено...


В EF уже сто лет так. И лейзи есть, и отслеживание изменений. И полная поддержка POCO, чего хиберу не снилось.
Еще бы коллекции прятать. Хотя бы за IEnumerable

да лана, коде ферст запилили, дальше все как у хибера будет
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086093
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttпропущено...


Это что угодно с идентификатором.Я б всё таки сказал, что обладает уникальностью.

Ну а на практике это -- с идентификатором
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086094
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.Еще бы коллекции прятать. Хотя бы за IEnumerable

Нафига???

Я долго пытался выяснить у одного коллеги из другой команды, в чём зло IQueryable<>, но так и не услышал ничего кроме «плохо и всё!!!»
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086099
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

ну потому что я не могу замапить икверибл. Нужен иколлекшн. А значит в нем есть метод адд. А значит я не могу, например, сделать нормальную валидацию на добавление. Типа, у меня есть метод Add(), а рядом лежит иколекшн с котором я делаю что хочу...
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086100
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.,

а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086103
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.hVostt,

ну потому что я не могу замапить икверибл. Нужен иколлекшн. А значит в нем есть метод адд. А значит я не могу, например, сделать нормальную валидацию на добавление. Типа, у меня есть метод Add(), а рядом лежит иколекшн с котором я делаю что хочу...

Всё правильно. Именно поэтому Entity из мира EF/NH никак не тянет на Domain Object. А попытки запилить DO через интерфейс жалки и унылы.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086104
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAпропущено...
Я б всё таки сказал, что обладает уникальностью.

Ну а на практике это -- с идентификатором Вот так вот и кладут болт на теорию

1. Идентификация часто естественная: имя, фамилия, номер паспорта;
2. Когда проектируешь систему, что работает с хотя бы дестяком сторонних поставщиков и потребителей, в каждом из которых сущность идентифицируется по-разному, то думаешь шире, а не "что угодно с Id".
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086105
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttв чём зло IQueryable<>

тем что датаконтектст переходит в сервисы?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086106
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

и да и нет, с одной стороны они унылы, с другой уже приват сетеры появились. То-ли еще будет) Я раньше так не делал, а вот, недавно сделал, и знаешь, мне на самом деле нравится. Конечно есть ряд отвратительных моментов, но вполне с ними можно мериться.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086107
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.Denis.,

а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное)Особенно когда для источника данных никто за вас не реализовал икверибл провайдер :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086109
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANADenis.Denis.,

а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное)Особенно когда для источника данных никто за вас не реализовал икверибл провайдер :)

какой прок от него, когда запрос на SQL
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086110
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttя был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел

а что такого беспредельного? зато архитектурная ясность.
прально мыслишь, все что касается модели, должна явно определяться в модели, в виде структуры или поведения
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086111
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусь
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086112
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttв чём зло IQueryable<>

тем что датаконтектст переходит в сервисы?Оп, вот уже и репозиторий удалился.

Сервисы работают с репозиториями, то есть ничего не знают ни про EF-ский датаконтекст, ни про NH-скую сессию, ни про Mongo-вский клиент.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086113
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.Denis.,

а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное)

Я исхожу из следующей суперпозиции:

1. Тестируемость.
2. Сопровождаемость.
3. Понятность.
4. Удобство дальнейшей разработки.

Конечно, круто запилить 10 слоёв абстракций и тысячи мелких классов-спецификаций/команд/ивентов... Это очень круто! Прям медаль большая позолоченная так и просится на грудь архитектору года. Но если с этим работать тяжело, если новичок в команде будет въезжать в эту муть неделю, то в топку. Нафиг. Отправили чувака с медалью на конференцию, и пусть он там потеряется.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086115
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусь

ой, не зарекайтесь.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086116
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.skyANA,

ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусьЧто из области фантастики? Я работал с вполне реальными системами онлайн-бронирования :)
Покажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086117
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


тем что датаконтектст переходит в сервисы?Оп, вот уже и репозиторий удалился.

Сервисы работают с репозиториями, то есть ничего не знают ни про EF-ский датаконтекст, ни про NH-скую сессию, ни про Mongo-вский клиент.

а какже они там что-то потом джоинят? проекции делают?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086120
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Особенно когда для источника данных никто за вас не реализовал икверибл провайдер :)

какой прок от него, когда запрос на SQLОт кого от него?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086121
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAВот так вот и кладут болт на теорию

Теория без практики -- ноль без палочки.


skyANA1. Идентификация часто естественная: имя, фамилия, номер паспорта;

Угу, выскочила девушка замуж и слетела идентификация. Сменил паспорт из-за утери, слетела идентификация.

Это же уже сто пицот раз измусоленный вдоль и поперёк вопрос! Начиналось всё с красивой сказки, с натуральных идентификаторов. И где они сейчас?

skyANA2. Когда проектируешь систему, что работает с хотя бы дестяком сторонних поставщиков и потребителей, в каждом из которых сущность идентифицируется по-разному, то думаешь шире, а не "что угодно с Id".

Что угодно с Id. Данные из сторонних систем связываются таким образом: <Их ID>—<Наш ID>. Да, <их ID> может быть комплексным, а у нас в единой системе — нет. Точнее, могло бы быть... Но нет.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086122
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANADenis.skyANA,

ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусьЧто из области фантастики? Я работал с вполне реальными системами онлайн-бронирования :)
Покажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :)

нет, я имел ввиду, конечно, репозиторий на базу. Для внешних систем, конечно, плохой вариант.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086123
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Оп, вот уже и репозиторий удалился.

Сервисы работают с репозиториями, то есть ничего не знают ни про EF-ский датаконтекст, ни про NH-скую сессию, ни про Mongo-вский клиент.

а какже они там что-то потом джоинят? проекции делают?Вопросы какие-то нелепые начались. Где там и кто кого джойнит?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086124
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttв чём зло IQueryable<>

тем что датаконтектст переходит в сервисы?

Не переходит. Ты не можешь изменить набор данных через IQueryable<>. Ни добавить, ни удалить.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086125
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


а какже они там что-то потом джоинят? проекции делают?Вопросы какие-то нелепые начались. Где там и кто кого джойнит?

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1181398&msg=18323043
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086126
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAОсобенно когда для источника данных никто за вас не реализовал икверибл провайдер :)

Это ж вызов! Challenge! Почему нет-то?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086127
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.skyANA,

ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусь

Я сталкивался. И не раз. Переходили и на Postgres с MS SQL, и хибер выпиливали в пользу EF. Так что...
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086128
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну, чувствую, что народ уже набрал определенный багаж и готов критически осмыслить "технологии"
значит жди в скорости крутых обновлений в "технологиях" - засиделись фулеры, пора народ вернуть к нулю - боднию с биндингами и хамлами (а как там комбобокс забиндить?), всякими там енумерейбле, хренейбле :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086129
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAОсобенно когда для источника данных никто за вас не реализовал икверибл провайдер :)

Это ж вызов! Challenge! Почему нет-то? А для на фига козе баян, если конкретный API, что в сто раз уже возможностей икверибла? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086130
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAПокажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :)

Дык профит же очевиден. Один раз провайдер реализовать, чем сто-пицот разных отдельных спецификаций или ещё хуже, методов в репозитории.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086133
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAПокажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :)

Дык профит же очевиден. Один раз провайдер реализовать, чем сто-пицот разных отдельных спецификаций или ещё хуже, методов в репозитории.Каким это образом один раз? Если у Амадеуса один API, у Куони второй, у Травко третий и т.д.? :) Или давай поверх них сначала навернём абстракций, да?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086134
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAА для на фига козе баян, если конкретный API, что в сто раз уже возможностей икверибла? :)

Странный вопрос. IQueryable -- стандарт для мира дотнета, а какой-то конкретный АПИ нет.

А зачем СУБД реализуют SQL? Надо было каждому вендуру свой язык выдумать, ни разу не похожий ни на чей другой.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086135
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAКаким это образом один раз? Если у Амадеуса один API, у Куони второй, у Травко третий и т.д.? :) Или давай поверх них сначала навернём абстракций, да?

Каждому по провайдеру и дело в шляпе. Сделали и забыли.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086136
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Вопросы какие-то нелепые начались. Где там и кто кого джойнит?

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1181398&msg=18323043 Давайте обратимся к определению Data Transfer Object (Объект передачи данных) .
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086138
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAА для на фига козе баян, если конкретный API, что в сто раз уже возможностей икверибла? :)

Странный вопрос. IQueryable -- стандарт для мира дотнета, а какой-то конкретный АПИ нет.

А зачем СУБД реализуют SQL? Надо было каждому вендуру свой язык выдумать, ни разу не похожий ни на чей другой.А зачем есть DSL?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086139
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

это полная хрень (техническое решение) какого то тупого чека
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086141
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAА зачем есть DSL?

Ну так об этом и речь. Реализуешь провайдер и можешь юзать единый DSL (LINQ). А ты что предлагаешь? Провайдер тяжело тип реализовывать, вместо этого лучше... что?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086142
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAКаким это образом один раз? Если у Амадеуса один API, у Куони второй, у Травко третий и т.д.? :) Или давай поверх них сначала навернём абстракций, да?

Каждому по провайдеру и дело в шляпе. Сделали и забыли.Ну в итоге так и получается. Только не по икверибл провайдеру :)
А по реализации своего провайдера с нужным в этой предметной области интерфейсом.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086143
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosskyANA,

это полная хрень (техническое решение) какого то тупого чекаЧего?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086145
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAНу в итоге так и получается. Только не по икверибл провайдеру :)
А по реализации своего провайдера с нужным в этой предметной области интерфейсом.

Эмм.. никто не отменяет интерфейса для предметной области. Я только про запросы к данным из коллекции говорю, низкого уровня. Уберём IQueryable и заменим на некий универсальный транслятор domainSQL и по сути получим тоже самое.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086146
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAА зачем есть DSL?

Ну так об этом и речь. Реализуешь провайдер и можешь юзать единый DSL (LINQ). А ты что предлагаешь? Провайдер тяжело тип реализовывать, вместо этого лучше... что?Вообще-то я о том, что есть языки общено назначения, а есть DSL.

С намёком на то, что для конкретной задачи, в конкретной предметной области не надо стремиться реализовывать всю полноту возможностей икверибла :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086147
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
когда строишь мир свой, обычно какие то вещи невозможно соорудить непротиворечиво и красиво - так как аксиомы неверные
вот тут то начинаются троица там бл* дух зачем то приперся а тут папашу с сыном никак не идентифицировать
дальше пошли бабы, ипостолы, папы, попы и всякая иная нечисть
вот ДТО это типа Попа :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086149
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAВообще-то я о том, что есть языки общено назначения, а есть DSL.

С намёком на то, что для конкретной задачи, в конкретной предметной области не надо стремиться реализовывать всю полноту возможностей икверибла :)

А, с этим согласен. Всю полноту не всегда возможно будет реализовать, например, агрегацию или подзапросы.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086150
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAНу в итоге так и получается. Только не по икверибл провайдеру :)
А по реализации своего провайдера с нужным в этой предметной области интерфейсом.

Эмм.. никто не отменяет интерфейса для предметной области. Я только про запросы к данным из коллекции говорю, низкого уровня. Уберём IQueryable и заменим на некий универсальный транслятор domainSQL и по сути получим тоже самое.Хм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086151
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosкогда строишь мир свой, обычно какие то вещи невозможно соорудить непротиворечиво и красиво - так как аксиомы неверные
вот тут то начинаются троица там бл* дух зачем то приперся а тут папашу с сыном никак не идентифицировать
дальше пошли бабы, ипостолы, папы, попы и всякая иная нечисть
вот ДТО это типа Попа :)Если рассматривать DTO в рамках данного определения , то никой попы не наблюдается.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086154
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable?

А почему нет?

Код: c#
1.
2.
string odata_qry = "$filter=FirstName eq 'Hello' and LastName ne 'GoodBye'";
var linq_expression = MrODataUriParser.ToLinqExpression<PersonObject>(odata_qry);
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086155
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

я как раз посмотрел и потому написал тот пост
если чек не удосужился понять, что в два чека это мир видя по разному!! то он хотя бы должен был ввести Понятие - Трансформация моделей (со всеми вытекающими), а не фигню, что в голову пришло для залатания устройства своего мирка
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086157
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086158
Фотография Denis.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable?
да. так проще.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086183
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable?

А почему нет?

Код: c#
1.
2.
string odata_qry = "$filter=FirstName eq 'Hello' and LastName ne 'GoodBye'";
var linq_expression = MrODataUriParser.ToLinqExpression<PersonObject>(odata_qry);

Ну потому как expression тут лишнее. Как и OData.

Мы имеем сильно ограниченный набор фильтров (условий, критериев поиска), что легко выражаются объектами предметной области.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086186
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Denis.skyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable?
да. так проще.Чем же это проще? Проще чего?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086187
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosskyANA,

я как раз посмотрел и потому написал тот пост
если чек не удосужился понять, что в два чека это мир видя по разному!! то он хотя бы должен был ввести Понятие - Трансформация моделей (со всеми вытекающими), а не фигню, что в голову пришло для залатания устройства своего миркаДавай конкретнее.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086195
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAНу потому как expression тут лишнее. Как и OData.

OData лишь для примера. А expression отлично выражает мысль при запросе данных в .NET, почему лишнее? Ну будет не expression, а какой-то кастомный способ для запроса данных, т.е. ты попросту плодишь новые сущности: интерфейсы там, где этого можно было бы избежать.


skyANAМы имеем сильно ограниченный набор фильтров (условий, критериев поиска), что легко выражаются объектами предметной области.

Да ради бога. Только твою предметную область может слопать лишь ограниченное количество потребителей, высокий уровень связности.

Вот для примера. Мы решили применить новый набор контролов. Он кушает IQueryable, потому что разработчики контролов понятия не имеют о твоих предметных областях, и не должны. А так как у нас повсюду IQueryable, мы просто скормили их и оставшееся время посвятили другим задачам. В ином случае нам бы пришлось пилить целую армию адаптеров, на что просто убили бы много времени.

Это просто для примера, его можно покритиковать, типа а нафига мы будем брать какие-то контролы, мы свои запилим, под свои интерфейсы. Ну-ну...
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086196
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAВопросы какие-то нелепые начались.

да просто вы с хвостом начали флудить
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086197
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAВопросы какие-то нелепые начались.

да просто вы с хвостом начали флудить

Да нет, мы всё выяснили. Ты тупо запилил для кучи Entity классов их дублёры DTO, чтобы эээ... спрятать Entity, иного объяснения я не вижу. Не понятно чё в таком случае тут делают дата-сервисы, вся бизнес логика осела в репозитории. В общем смешались в кучу кони, люди..
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086198
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAViPRosкогда строишь мир свой, обычно какие то вещи невозможно соорудить непротиворечиво и красиво - так как аксиомы неверные
вот тут то начинаются троица там бл* дух зачем то приперся а тут папашу с сыном никак не идентифицировать
дальше пошли бабы, ипостолы, папы, попы и всякая иная нечисть
вот ДТО это типа Попа :)Если рассматривать DTO в рамках данного определения , то никой попы не наблюдается.

а кто его по-другому рассматривает?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086201
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAНу потому как expression тут лишнее. Как и OData.

OData лишь для примера. А expression отлично выражает мысль при запросе данных в .NET, почему лишнее? Ну будет не expression, а какой-то кастомный способ для запроса данных, т.е. ты попросту плодишь новые сущности: интерфейсы там, где этого можно было бы избежать.


skyANAМы имеем сильно ограниченный набор фильтров (условий, критериев поиска), что легко выражаются объектами предметной области.

Да ради бога. Только твою предметную область может слопать лишь ограниченное количество потребителей, высокий уровень связности.

Вот для примера. Мы решили применить новый набор контролов. Он кушает IQueryable, потому что разработчики контролов понятия не имеют о твоих предметных областях, и не должны. А так как у нас повсюду IQueryable, мы просто скормили их и оставшееся время посвятили другим задачам. В ином случае нам бы пришлось пилить целую армию адаптеров, на что просто убили бы много времени.

Это просто для примера, его можно покритиковать, типа а нафига мы будем брать какие-то контролы, мы свои запилим, под свои интерфейсы. Ну-ну...Эххх... Мою предметную область могут слопать решения на PHP, Java, Ruby и т.д. Как же у них это получится, когда нету там IQueryable? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086202
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttвся бизнес логика осела в репозитории


Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
public InfoSystemDTO Save(long userId, InfoSystemDTO dto)
        {
            checkStringConstraint("Name", dto.Name, true, 70, 2);
            checkStringConstraint("ShortName", dto.ShortName, true, 70, 2);
            
            if (messages.Count > 0)
                throw new DataServiceException("Не корректно заполненные поля формы", messages);
            
            return infoSystemRepository.Save(userId, dto);
            
        }



Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
public InfoSystemDTO Save(long userId, InfoSystemDTO dto)
        {
            InfoSystem domain = null;
            if (dto.Id > 0)
            {
                domain = context.InfoSystems.Find(dto.Id);
                domain.UserUpdateId = userId;
                domain.DateUpdate = DateTime.Now;
                domain.Version++;
            }
            else
            {
                domain = new InfoSystem()
                {
                    DateInsert = DateTime.Now,
                    UserInsertId = userId
                };
                context.InfoSystems.Add(domain);
            }

            domain.Name = dto.Name;
            domain.ShortName = dto.ShortName;
            domain.InfoSystemTypeId = dto.InfoSystemTypeId;

            context.SaveChanges();

            return Mapper.Map<InfoSystem, InfoSystemDTO>(domain);
        }



где тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппинг
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086203
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Если рассматривать DTO в рамках данного определения , то никой попы не наблюдается.

а кто его по-другому рассматривает?Ты. По-своему :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086204
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


а кто его по-другому рассматривает?Ты. По-своему :)

это тебе так кажется
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086206
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawhVosttвся бизнес логика осела в репозитории


Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
public InfoSystemDTO Save(long userId, InfoSystemDTO dto)
        {
            checkStringConstraint("Name", dto.Name, true, 70, 2);
            checkStringConstraint("ShortName", dto.ShortName, true, 70, 2);
            
            if (messages.Count > 0)
                throw new DataServiceException("Не корректно заполненные поля формы", messages);
            
            return infoSystemRepository.Save(userId, dto);
            
        }



Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
public InfoSystemDTO Save(long userId, InfoSystemDTO dto)
        {
            InfoSystem domain = null;
            if (dto.Id > 0)
            {
                domain = context.InfoSystems.Find(dto.Id);
                domain.UserUpdateId = userId;
                domain.DateUpdate = DateTime.Now;
                domain.Version++;
            }
            else
            {
                domain = new InfoSystem()
                {
                    DateInsert = DateTime.Now,
                    UserInsertId = userId
                };
                context.InfoSystems.Add(domain);
            }

            domain.Name = dto.Name;
            domain.ShortName = dto.ShortName;
            domain.InfoSystemTypeId = dto.InfoSystemTypeId;

            context.SaveChanges();

            return Mapper.Map<InfoSystem, InfoSystemDTO>(domain);
        }



где тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппингАдъ :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086207
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...



Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
public InfoSystemDTO Save(long userId, InfoSystemDTO dto)
        {
            checkStringConstraint("Name", dto.Name, true, 70, 2);
            checkStringConstraint("ShortName", dto.ShortName, true, 70, 2);
            
            if (messages.Count > 0)
                throw new DataServiceException("Не корректно заполненные поля формы", messages);
            
            return infoSystemRepository.Save(userId, dto);
            
        }




Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
public InfoSystemDTO Save(long userId, InfoSystemDTO dto)
        {
            InfoSystem domain = null;
            if (dto.Id > 0)
            {
                domain = context.InfoSystems.Find(dto.Id);
                domain.UserUpdateId = userId;
                domain.DateUpdate = DateTime.Now;
                domain.Version++;
            }
            else
            {
                domain = new InfoSystem()
                {
                    DateInsert = DateTime.Now,
                    UserInsertId = userId
                };
                context.InfoSystems.Add(domain);
            }

            domain.Name = dto.Name;
            domain.ShortName = dto.ShortName;
            domain.InfoSystemTypeId = dto.InfoSystemTypeId;

            context.SaveChanges();

            return Mapper.Map<InfoSystem, InfoSystemDTO>(domain);
        }




где тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппингАдъ :)

почему?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086210
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Ты. По-своему :)

это тебе так кажетсяНе кажется. У меня от смены хранилища понятия не меняются :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086211
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


это тебе так кажетсяНе кажется. У меня от смены хранилища понятия не меняются :)

у меня тоже
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086213
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Не кажется. У меня от смены хранилища понятия не меняются :)

у меня тожеНу-ну... Хранили в РСУБД, использовали ORM, User был entity. Стали хранить в MongoDB и User стал DTO :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086215
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Адъ :)

почему?У тебя в одну сторону маппинг в одну строку, в обратную в 20.
При этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086217
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAУ тебя в одну сторону маппинг в одну строку, в обратную в 20.

это фигня
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086219
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAПри этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости.

поясни, плиз
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086226
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И ещё. Для на фига метод Save возвращает объект того же типа, что и получает на вход?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086229
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAУ тебя в одну сторону маппинг в одну строку, в обратную в 20.

это фигняНу ну... А в чём вообще смысл InfoSystemDTO? Тупо проекция?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086230
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAИ ещё. Для на фига метод Save возвращает объект того же типа, что и получает на вход?

потому что из БД запрашивает.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086231
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


это фигняНу ну... А в чём вообще смысл InfoSystemDTO? Тупо проекция?

тупо да
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086236
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmaw,

он и не может быть ничем иным
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086241
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAПри этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости.

skyANA, это ты про что?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086242
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAИ ещё. Для на фига метод Save возвращает объект того же типа, что и получает на вход?

потому что из БД запрашивает.Чего? Это получается, что любой другой разработчик, кто хочет использовать твой репозиторий, должен быть в курсе нюансов его реализации?

Оказывается метод Save не просто сохраняет состояние объекта в том виде, в каком оно есть, но ещё что-то из БД запрашивает.
А если хранилище изменилось, то это "запрашивает" тоже реализовывать надо?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086244
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAПри этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости.

skyANA, это ты про что?Про Id > 0.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086245
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


потому что из БД запрашивает.Чего? Это получается, что любой другой разработчик, кто хочет использовать твой репозиторий, должен быть в курсе нюансов его реализации?

Оказывается метод Save не просто сохраняет состояние объекта в том виде, в каком оно есть, но ещё что-то из БД запрашивает.
А если хранилище изменилось, то это "запрашивает" тоже реализовывать надо?

а что там реализовывать-то. всю реализацию уже привел выше.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086246
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAА если хранилище изменилось, то это "запрашивает" тоже реализовывать надо?

конечно
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086247
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAА если хранилище изменилось, то это "запрашивает" тоже реализовывать надо?

конечноКлассный контракт! :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086248
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


skyANA, это ты про что?Про Id > 0.

тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так.

подскажи как правильно
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086250
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Про Id > 0.

тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так.

подскажи как правильноИспользовать средства ORM, раз уж используешь.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086252
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...


тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так.

подскажи как правильноИспользовать средства ORM, раз уж используешь.
skyANAkmawпропущено...


тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так.

подскажи как правильноИспользовать средства ORM, раз уж используешь.

вот это лишнее?

Код: c#
1.
domain = context.InfoSystems.Find(dto.Id);
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086253
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAЭххх... Мою предметную область могут слопать решения на PHP, Java, Ruby и т.д. Как же у них это получится, когда нету там IQueryable? :)

Ты какую-то фигню говоришь. При чём тут PHP? Я говорю про интерфейсы внутри NET, ты пихаешь мне PHP. Так-то твою предметную область никто не слопает. А если ты реализуешь OData, то получишь и IQueryable и лопать может кто угодно, хоть PHP, хоть Java, хоть упоротый чёрт на куличах.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086254
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Использовать средства ORM, раз уж используешь.
skyANAпропущено...
Использовать средства ORM, раз уж используешь.

вот это лишнее?

Код: c#
1.
domain = context.InfoSystems.Find(dto.Id);

Судя по коду, да.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086255
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawгде тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппинг

вижу кусок бизнеса, а не маппинг. маппинг реализуется на Automapper, и при чём двух-сторонний, а у тебя односторонний. и профита не вижу, и вообще это жесть адская.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086257
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttkmawгде тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппинг

вижу кусок бизнеса, а не маппинг. маппинг реализуется на Automapper, и при чём двух-сторонний, а у тебя односторонний. и профита не вижу, и вообще это жесть адская.

где кусок бизнеса ты видешь?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086258
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...

пропущено...


вот это лишнее?

Код: c#
1.
domain = context.InfoSystems.Find(dto.Id);


Судя по коду, да.

это всё игра в прятки с ORM/Entity =)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086260
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawгде кусок бизнеса ты видешь?

if..else..Version++, кроме того Save сидит здесь, с какого перепугу? это уже бизнес, он отвечает за то, когда именно надо данные сохранить в контексте бизнес-транзакции. в общем, всё переделать.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086261
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAkmawпропущено...

пропущено...


вот это лишнее?

Код: c#
1.
domain = context.InfoSystems.Find(dto.Id);


Судя по коду, да.

т.е. при наличии Id > 0 все равно можно
Код: c#
1.
domain = new Domain(){Id = id}


?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086262
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAЭххх... Мою предметную область могут слопать решения на PHP, Java, Ruby и т.д. Как же у них это получится, когда нету там IQueryable? :)

Ты какую-то фигню говоришь. При чём тут PHP? Я говорю про интерфейсы внутри NET, ты пихаешь мне PHP. Так-то твою предметную область никто не слопает. А если ты реализуешь OData, то получишь и IQueryable и лопать может кто угодно, хоть PHP, хоть Java, хоть упоротый чёрт на куличах.Какую ещё фигню? Ты же позиционируешь IQueryable как некую фишку для каких-то там потребителей.
А на практике конкуренты могут отжать часть ниши без твоих заморочек. Реализовав ограниченный предметной областью API.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086263
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttкроме того Save сидит здесь

так он в транзакции. а она в сервисе.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086264
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А про контролы, заточенные только под икверибл, я вообще молча смеюсь :) Особенно под мобилу UI Kit-ы так все сплошь и рядом на икверибл заточены :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086267
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAКакую ещё фигню? Ты же позиционируешь IQueryable как некую фишку для каких-то там потребителей.
А на практике конкуренты могут отжать часть ниши без твоих заморочек. Реализовав ограниченный предметной областью API.

И чем же плох IQueryable, как часть API? Никакая это не фишка, это конкретный интерфейс и LINQ — сегодня стандарт де-факто в мире .NET. Его можно использовать больше, чем средство для работы с коллекциями и ORM. Он сериализуется и десериализуется, что открывает путь «наружу» в твои любимые руби и питоны. Что ещё надо?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086268
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmawskyANAпропущено...
Судя по коду, да.

т.е. при наличии Id > 0 все равно можно
Код: c#
1.
domain = new Domain(){Id = id}


?Хм... Я конечно EF не использую, но вроде как там Attach к контексту выполнить можно не только через Find :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086269
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAКакую ещё фигню? Ты же позиционируешь IQueryable как некую фишку для каких-то там потребителей.
А на практике конкуренты могут отжать часть ниши без твоих заморочек. Реализовав ограниченный предметной областью API.

И чем же плох IQueryable, как часть API? Никакая это не фишка, это конкретный интерфейс и LINQ — сегодня стандарт де-факто в мире .NET. Его можно использовать больше, чем средство для работы с коллекциями и ORM. Он сериализуется и десериализуется, что открывает путь «наружу» в твои любимые руби и питоны. Что ещё надо?Ничем не плох и не хорош. Много времени только на него зря тратить.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086270
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAAttach к контексту

вот за это спасибо
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086271
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAА про контролы, заточенные только под икверибл, я вообще молча смеюсь :) Особенно под мобилу UI Kit-ы так все сплошь и рядом на икверибл заточены :)

Серверные реализации да. Чоб нет-то?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086273
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAА про контролы, заточенные только под икверибл, я вообще молча смеюсь :) Особенно под мобилу UI Kit-ы так все сплошь и рядом на икверибл заточены :)

Серверные реализации да. Чоб нет-то?По статистике в серверной реализации лидирует PHP. Подо что больше будут писать контролы? :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086303
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAПо статистике в серверной реализации лидирует PHP. Подо что больше будут писать контролы? :)

Вот ты прицепился к этому PHP, хрен отцепишь. Какая нафиг разница какие там позиции в мире занимает PHP? Что это меняет? Типа контролов под дотнетов нет? Открою великую тайну: есть и хватает! Мне этот PHP задаром не упал, совершенно наплевать что там и как там в мире PHP совершенно. Мне не платят за разработку PHP, я не учился и не практиковался на PHP, и даже малейшего желания не испытываю. Абсолютное большинство разработчиков .NET сидят в энтерпрайзе, и я тоже, а в энтерпрайзе никакими PHP даже не пахнет. Так зачем говорить PHP-PHP-PHP?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086348
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAПо статистике в серверной реализации лидирует PHP. Подо что больше будут писать контролы? :)

Вот ты прицепился к этому PHP, хрен отцепишь. Какая нафиг разница какие там позиции в мире занимает PHP? Что это меняет? Типа контролов под дотнетов нет? Открою великую тайну: есть и хватает! Мне этот PHP задаром не упал, совершенно наплевать что там и как там в мире PHP совершенно. Мне не платят за разработку PHP, я не учился и не практиковался на PHP, и даже малейшего желания не испытываю. Абсолютное большинство разработчиков .NET сидят в энтерпрайзе, и я тоже, а в энтерпрайзе никакими PHP даже не пахнет. Так зачем говорить PHP-PHP-PHP? Ты включил дурака типа? Ну ладно, тогда проехали.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086371
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAТы включил дурака типа? Ну ладно, тогда проехали.

У меня недоумение, почему у тебя практически всегда не к месту всплывают какие-то Ruby, PHP, Java? Это заболевание гика такое? Тебя загикали?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086409
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
blest,
все зависит от потребностей:
* минимальный набор - это сущность, без бизнес логики в этой сущности, делаешь маппинг на таблицы бд при помощи какой либо орм и эту же сущность же используешь во всех слоях - бизнес и презентационном

дальше по нарастающей
* у тебя могут появиться несколько интерфейсов для редактирования одной сущности, но с разным набором полей - делаешь несколько model и маппинг model в сущность, чтоб не загрязнять сущность
* у тебя появляются проблемы с crud операциями, например веб - телерик кендо - entity framework: без моделей эта связка будет выносить тебе мозг - сделаешь model и маппинг на сущность - все встанет на свои места
* ты можешь сделать полноценные доменные сущности с бизнес логикой и уже не сможешь легко и просто замапить их на таблицы бд - делаешь отдельный набор моделей для orm и маппинга на таблицы, а доменные сущности маппишь в эти модели orm
* у тебя появится сервис для внешних потребителей - ты не сможешь отдать им доменные сущности, только dto (= model), которые будут сериализовываться в xml/json
* и так далее и тому подобное

твои внутренние бизнес-службы с логикой могут работать как с сущностями так и с моделями, просто организуй понятным образом

и еще почитай еще про cqrs - избавишься от мега-служб с кучей методов
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086489
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAТы включил дурака типа? Ну ладно, тогда проехали.

У меня недоумение, почему у тебя практически всегда не к месту всплывают какие-то Ruby, PHP, Java? Это заболевание гика такое? Тебя загикали? А ты высуни голову из своего энтерпрайза и попытайся понять :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086536
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAА ты высуни голову из своего энтерпрайза и попытайся понять :)

А чё там понимать, есть JSON и XML кому надо, и плевать как там внешний PPP называется.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39086711
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAА ты высуни голову из своего энтерпрайза и попытайся понять :)

А чё там понимать, есть JSON и XML кому надо, и плевать как там внешний PPP называется.Скорее так: плевать рынок и конкуренты хотели на икверибл.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39087355
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAhVosttпропущено...


А чё там понимать, есть JSON и XML кому надо, и плевать как там внешний PPP называется.Скорее так: плевать рынок и конкуренты хотели на икверибл.

Хм.. ты используешь C# интерфейсы и классы? А как же PHP? Они понимают эти интерфейсы и классы? Или плевать на рынок, хотели средства платформы и языка?

Бредятину какую-то несёшь, чесслово. Для обмена с внешим миром есть расово верные XML и JSON, независит ни от платформы, ни от языка. Или я чего-то в твоём послании явно не понимаю
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39087424
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttskyANAпропущено...
Скорее так: плевать рынок и конкуренты хотели на икверибл.

Хм.. ты используешь C# интерфейсы и классы? А как же PHP? Они понимают эти интерфейсы и классы? Или плевать на рынок, хотели средства платформы и языка?

Бредятину какую-то несёшь, чесслово. Для обмена с внешим миром есть расово верные XML и JSON, независит ни от платформы, ни от языка. Или я чего-то в твоём послании явно не понимаю Явно не понимаешь.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39087543
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAЯвно не понимаешь.

Ок, д'Артаньян
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39087550
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, Планше, где моё бургундское?
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39087774
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAКстати, Планше, где моё бургундское?

Есть только торт и крендельки
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39090292
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О, на DotNext Дино Эспозито выступит с двумя докладами о важности доменной модели и проектировании на основе предметной области.
Надо ему сказать будет, что нет ORM, значит нет Entity :)
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39090479
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANAО, на DotNext Дино Эспозито выступит с двумя докладами о важности доменной модели и проектировании на основе предметной области.
Надо ему сказать будет, что нет ORM, значит нет Entity :)

Не знал, что он работает в JetBrains... считаю, что по этой теме хватит уже евангелизмом заниматься, нужны конкретные практики.
...
Рейтинг: 0 / 0
Архитектура приложения, надо ли дублировать сущности под каждый слой
    #39091365
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хвост, скайна, спасибо за критику. я многое переосмыслил. вы правы. полезный оказался топик
...
Рейтинг: 0 / 0
295 сообщений из 295, показаны все 12 страниц
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Архитектура приложения, надо ли дублировать сущности под каждый слой
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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