|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
В моем понимании схема проекта должна быть такой: Получается в данной схеме на одну сущность БД (Entity) мы дважды дублируем данную сущность для других слоев - для BLL и для слоя приложения. 1) Правильно ли я все понимаю схему 2) допускается ли наследование DataModel От Entity или лучше независимые классы создать 3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 19:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blest, лучше использовать модель , а остальное пофиг ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 19:55 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
назовите: DataModel - DTO Model - ViewModel BLLayer - DataService и по схеме: DTO от Entity не зависит, Entity может вообще отсутствовать DataService и Repository зависит от DTO ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blest2) допускается ли наследование DataModel От Entity или лучше независимые классы создать только независимые ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:02 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую можно, но я не видел ни одного проекта, когда это дало бы профит ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:04 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawblest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую можно, но я не видел ни одного проекта, когда это дало бы профит а какие ты проекты воще видел? (давай погавкаемся) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRoskmawпропущено... можно, но я не видел ни одного проекта, когда это дало бы профит а какие ты проекты воще видел? (давай погавкаемся) на такой чОткий вопрос так сразу и не ответишь. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw, ну давай почетче что там ДатаМодел и что там ентити и почему чувиха хочет датамодел из ентити наследовать? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:16 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRoskmaw, ну давай почетче что там ДатаМодел и что там ентити и почему чувиха хочет датамодел из ентити наследовать? "и почему чувиха хочет датамодел из ентити наследовать" - он думает, что это копипаст. он заблуждается. пример: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
где, Код: c# 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosлучше использовать модель , а остальное пофиг читал твои мысли в разных топиках на эту тему. ты вкладываешь в этот термин свое ViPRos-вское понятие модели. тут все более прозаично ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 20:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
лично я так и делаю. в солюшене есть проект слоя данных, в нем все сущности базы и сервисы для загрузки, в другом проекте поставщики данных (Provider), классы которые используя серверы предоставляют доступ к observable коллекциям, обновляют их и т.д. в третьем проекте модели представления и как правило сразу же рядом с ними View'и (XAML ресурсы, без CodeBehind, я использую только шаблоны (DataTemplate), стили и если надо спец. панели и контролы, но часто панели и контролы тоже выношу в отдельный проект. После этого, остается только в ViewModel получить из поставщика нужную коллекцию, из поставщика я уже получаю объекты для ViewModel, а о слое данных ViewModel особо и не в курсе. По сути Provider'ы, это часть ViewModel'и но вынесенная отдельно. Мне так удобно, во первых. Мне не нужно париться об обновлении данных в ViewModel, так как всё это вынесено в Provider'ы, провайдер сам создает ObservableCollection<T>, сам регулярно подключается к базе и проверяет, не обновился ли список, вставляет и удаляет записи и создает. Делается всё это при помощи сервисов Да писать приходится больше, но в дальнейшем я только выигрываю.: а) сервисы для загрузки из бд у меня универсальные и сделаны на базе рефлексии, то есть загрузка происходит автоматом, нужно только для класса определяющего сущность записи бд прописать нужные аттрибуты или задать правильно имена свойство по полям. Если я работаю с БД. б) загрузка данных происходит только 1 раз, разные модели представления могут получить доступ к одному поставщику данных, мне не надо каждый раз заботится о всех сопутствующих проблемах. Как по мне, делать нужно так, как удобно и легко. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 21:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blest1) Правильно ли я все понимаю схему Если под «правильно» понимается «мы дважды дублируем данную сущность», то нет. Ибо, что такое сущность? Табличка в базе данных? Сущность в контексте репозитория / ORM, отражает то, как данные хранятся, немного скрывая свою реляционную природу. В теории, сущности могут лежать вовсе не в реляционной структуре, а в какой-нибудь NoSQL, или ещё где-то, и нам это должно быть не важно. Но это всё лирика, и лежит в плоскости более практичной — мы прекрасно знаем где и как данные будут лежать, всё что слой доступа к данным делает, это типизирует эти данные, ну и немного (совсем немного), скрывает конкретику природы хранилища. Т.е. MS SQL мы можем заменить на какой-нибудь Oracle, и это должно прокатить. А под DataModel понимается скорее всего DTO — это конкретные кортежи данных, которые вовсе не обязаны соответствовать табличкам. Например, у тебя есть некий грид и 10 колонок, чтобы их получить, надо собрать данные из 5 таблиц, вот и выбирай: либо 5 сущностей, либо 1 DTO. А как 5 сущностей превратить в 1 DTO? Ответ — проекция, чувак. Проекция! :) В общем, ответ на первый вопрос: скорее нет, чем да. blest2) допускается ли наследование DataModel От Entity или лучше независимые классы создать Нет! Не допускается. Даже не вижу смысла отвечать на вопрос «почему?», ведь эти классы служат совершенно разным целям и решают разные задачи. blest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую Можно со временем состряпать свой некий bootstrapper, который будет содержать каркас, с которым удобно работать. Если каркас получился удачным, то большая часть предметной области может в него удобно лечь. Ну а это уже приходит с опытом. Ну и задачи со временем становятся довольно таки однотипными. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 21:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Roman Mejtesлично я так и делаю. в солюшене есть проект слоя данных, в нем все сущности базы и сервисы для загрузки, в другом проекте поставщики данных (Provider), классы которые используя серверы предоставляют доступ к observable коллекциям, обновляют их и т.д. в третьем проекте модели представления и как правило сразу же рядом с ними View'и (XAML ресурсы, без CodeBehind, я использую только шаблоны (DataTemplate), стили и если надо спец. панели и контролы, но часто панели и контролы тоже выношу в отдельный проект. После этого, остается только в ViewModel получить из поставщика нужную коллекцию, из поставщика я уже получаю объекты для ViewModel, а о слое данных ViewModel особо и не в курсе. По сути Provider'ы, это часть ViewModel'и но вынесенная отдельно. Мне так удобно, во первых. Мне не нужно париться об обновлении данных в ViewModel, так как всё это вынесено в Provider'ы, провайдер сам создает ObservableCollection<T>, сам регулярно подключается к базе и проверяет, не обновился ли список, вставляет и удаляет записи и создает. Делается всё это при помощи сервисов Да писать приходится больше, но в дальнейшем я только выигрываю.: а) сервисы для загрузки из бд у меня универсальные и сделаны на базе рефлексии, то есть загрузка происходит автоматом, нужно только для класса определяющего сущность записи бд прописать нужные аттрибуты или задать правильно имена свойство по полям. Если я работаю с БД. б) загрузка данных происходит только 1 раз, разные модели представления могут получить доступ к одному поставщику данных, мне не надо каждый раз заботится о всех сопутствующих проблемах. Как по мне, делать нужно так, как удобно и легко. судя по вашему описанию, фигня какая-то. удобно только вам ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 22:02 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Roman MejtesПо сути Provider'ы, это часть ViewModel'и какой-то бред ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 22:03 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttМожно со временем состряпать свой некий bootstrapper ViPRos ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 22:11 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttМожно со временем состряпать свой некий bootstrapper ViPRos Нет, ВИПРОС это очердной замес на тему вечного двигателя и серебряной пули. Типа. А что, если нам заморочиться, и сделать такую волшебную хренобазу, в которой всё при всё создаётся без участия программистов? Сущности? Определяются на уровне данных, клац по кнопке, определил поля -- и готово! А вся при вся бизнес-логика тоже определяется на уровне данных, клац по кнопке, определил некий Workflow -- и готово! Вот сделать это всё и разогнать всех программистов к чёртовой матери. Путь идут пасутся, так как программисты больше не нужны. Нужен лишь один ВИПРОС и талмуд. =) А начинали подобные движения ещё сопливые немцы в будущей мегакорпорации SAP. И таки добились успехов. При чём не в реализации подобного, а в продажах. Так что всё впереди, готовьтесь программеры, ваш век подходит к концу ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 22:22 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttмегакорпорации SAP мстят за Сталинград ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 22:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Всем спасибо большое за ответы, ясность наступила. kmaw отдельное спасибо за исправления в схеме. Я только эту зависимость не понял kmawRepository зависит от DTO Если не сложно - каким образом DAL зависит от DTO ? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2015, 18:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blestВсем спасибо большое за ответы, ясность наступила. kmaw отдельное спасибо за исправления в схеме. Я только эту зависимость не понял kmawRepository зависит от DTO Если не сложно - каким образом DAL зависит от DTO ? предпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2015, 20:51 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawпредпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили ну в целом я так и думал. Но в таком случае описывать необходимо каждый репозиторий вручную (имею ввиду генериковое стандартное описание не подойдет) ?! ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2015, 21:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawпредпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили репо получает и отдаёт Entity, DTO получают/отдают дата-сервисы, иначе репо быстро превратится в God Object и потянет на себя бизнес-логику, чего категорически надо избегать. у репы банальная, и тупейшая в мире задача -- скрыть от остальной части ПО способ доступа к данным, Entity это у же и есть по сути DTO, только между миром БД и внутренней кухней ПО. зачем городить огород? DTO хороши, чтобы отдавать только то, что нужно. например, в Entity может быть сотня полей, плюс связи всякие. а сервису нужен только десяток и чуток полей из связей. сервису нафиг не упало получать отмаппленный по все помидоры Entity со всей сотней полей. для чего? ублажить Идею супер-мега-слоёного разделения? в погонях за красивыми картинками и схемками, люди частенько отдаляются от реальности и реальных задач примерно на пару парсеков. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2015, 22:20 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttрепо получает и отдаёт Entity такой вариант, наверное, для самых простых справочников "Id Name" годится. так как: отдаёт в подавляющем большинстве случаев возвращается join и проекция. да, там уже может быть некоторая логика типа decode (да и сложнее), но это, по-моему, неизбежно (причем, это может быть SQL). получает то, что принимается, - это также DTO по сути , даже если это класс Entity - {Id + набор свойств, по которым задается состояние объекта}. все равно придется объект сначала загрузить/создать, установить его состояние, а потом уже сохранить (причем, это может быть SQL). исходя из вышеперечисленного и следуют мои предпочтения. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 12:20 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawтакой вариант, наверное, для самых простых справочников "Id Name" годится глупости какие-то, ты меня не услышал, но я повторю: задача репо -- скрыть способ доступа к данным от остальной части ПО. репо великим русским языком -- это ХРАНИЛИЩЕ. а хранит он там Entity. соответственно, в задачи репо входит отдавать и принимать Entity, а не какие-то там DTO. поверх репо пилится дата сервисы (для анемичной модели данных), которые уже принимают и отдают DTO, и ПО работает с дата сервисами. да, Entity в идеале за пределами дата сервисов уже не видна. резюмирую: не надо сваливать на репо то, чем он не должен заниматься. репо не обязано знать ни о каких DTO, не должно заниматься маппингом и прочим. у него маленькая область ответстенности, и не надо на него сваливать что-то там ещё. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 13:04 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawтакой вариант, наверное, для самых простых справочников "Id Name" годится глупости какие-то, ты меня не услышал, но я повторю: задача репо -- скрыть способ доступа к данным от остальной части ПО. репо великим русским языком -- это ХРАНИЛИЩЕ. а хранит он там Entity. соответственно, в задачи репо входит отдавать и принимать Entity, а не какие-то там DTO. поверх репо пилится дата сервисы (для анемичной модели данных), которые уже принимают и отдают DTO, и ПО работает с дата сервисами. да, Entity в идеале за пределами дата сервисов уже не видна. резюмирую: не надо сваливать на репо то, чем он не должен заниматься. репо не обязано знать ни о каких DTO, не должно заниматься маппингом и прочим. у него маленькая область ответстенности, и не надо на него сваливать что-то там ещё. т.е. так должен выглядеть репозиторий? Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
тогда нафиг он нужен ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 14:54 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawт.е. так должен выглядеть репозиторий? да, примерно так. kmawтогда нафиг он нужен сколько раз мне ещё сказать про задачи, которые должен решать репозиторий??? в том виде, как ты указал -- он их решает. такой репозиторий можно замокать для тестов, можно легко подменить способ хранения данных. что ещё нужно-то? зачем в него какую-то логику ещё пихать? зачем эти ваши DTO вообще? разные части ПО могут требовать сотни разных не связанных DTO и связанной с этим логикой. при этом репозиторию накласть на это, он делает своё маленькое дело и в этом его великая ценность. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:17 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw, Как раз описанный Вами вариант репозитория инкапсилирует логику доступа к БД (я потому и задал уточняющий вопрос, т.к. не понял, как DTO вписывается в репозиторий), все join-ы(или include-ы) делаются в датасервисе. С EF действительно все описание репозитория укладывается в ~60 строчек, но попробуйте написать репозиторий хотя бы для ADO.NET ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:29 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttможно легко подменить способ хранения данных для такого репо это сделать не получится легко ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:34 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttтакой репозиторий можно замокать для тестов мой вариант тоже без проблем мокается ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttзачем в него какую-то логику ещё пихать? джоины и decode-логику куда пихать? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttразные части ПО могут требовать сотни разных не связанных DTO это сильно абстрактно. если что-то эдакое потребуется, может вообще потребоваться много чего переписать ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:38 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blestвсе join-ы(или include-ы) делаются в датасервисе я не испытываю прям органической неприязни к такому варианту, но тут, на мой взгляд, теряется сама надобность репозитория. тогда сам ОРМ можно считать репозиторием. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
все-равно, как не крути, есть "доменная логика". и в сервис её нормально не впихнешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blestвсе join-ы(или include-ы) делаются в датасервисе т.е. вариант с реализацией на нативном SQL отпадает ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 15:45 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blestС EF ... для ADO.NET в ADO.NET нет Entity. там есть только SQL и DTO. и там, наверное много логики в БД. но если надо феншуй - то легко: репо работают с DTO ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 16:03 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawblestС EF ... для ADO.NET в ADO.NET нет Entity. там есть только SQL и DTO. и там, наверное много логики в БД. но если надо феншуй - то легко: репо работают с DTO а захочется NHibernate - тоже без проблем, из датасервиса не надо будет выпиливать всякие останки от контекста, которые туда вместе с "все join-ы(или include-ы) делаются в датасервисе". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 16:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawkmawпропущено... в ADO.NET нет Entity. там есть только SQL и DTO. и там, наверное много логики в БД. но если надо феншуй - то легко: репо работают с DTO а захочется NHibernate - тоже без проблем, из датасервиса не надо будет выпиливать всякие останки от контекста, которые туда вместе с "все join-ы(или include-ы) делаются в датасервисе". хотя не пробовал, там с транзакциями наверное так сразу не получится ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 16:09 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawдля такого репо это сделать не получится легко серебряной пули не существует. но можешь поверить мне на слово, я подобный репо переводил с NHibernate на EF, и благодаря тому, что все обращения к БД делались исключительно через репо, а не через ISession, я это сделал за 1 день, при количестве Entity 100+ kmawмой вариант тоже без проблем мокается не правда, ты в репо инкапсулируешь кроме работу с Entity ещё и работу с DTO, так что не получится замокать только хранилище (например, подменить EF или NH на коллекции в памяти), не трогая ни один байт кода, работающий с DTO. kmawджоины и decode-логику куда пихать? в дата-сервисы. а если точнее, в механику проекций. ты как DTO из Entity получаешь? я исключительно 100% проекциями, и никак иначе. kmawэто сильно абстрактно. если что-то эдакое потребуется, может вообще потребоваться много чего переписать достаточно того, что это абстрактно, а что касается «эдакого» — это можно о чём угодно сказать. kmawвсе-равно, как не крути, есть "доменная логика". и в сервис её нормально не впихнешь. ты говоришь о анемичной модели (дата-сервисы, DTO), и о доменной логике в таком случае говорить не приходится. логику ты можешь пихнуть хоть в сервисы, хоть уровнем выше, но суть в том, что ты работаешь с кортежами данных. никакой доменной моделью тут даже и не пахнет (если брать картинки, которые в начале топике опубликованы). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:04 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blestно попробуйте написать репозиторий хотя бы для ADO.NETА что в этом сложного? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:05 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAblestно попробуйте написать репозиторий хотя бы для ADO.NETА что в этом сложного? надо будет состряпать ORM. чтобы сильно не возится, можно дёрнуть исходники EF или NH ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
DTO, Entity... Да у вас, парни, EF головного мозга :) Репозиторий может внутри себя использовать стратегию доступа к стороннему сервису, или даже сотне сервисов с разным API и форматом возвращаемых данных. Вот и подумайте, где у вас DTO, а где Entity :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:10 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:11 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAпропущено... А что в этом сложного? надо будет состряпать ORM. чтобы сильно не возится, можно дёрнуть исходники EF или NH Чтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:14 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:14 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... надо будет состряпать ORM. чтобы сильно не возится, можно дёрнуть исходники EF или NH Чтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно. Да, IDataReader будет достаточно, просто это уже не 60 строчек кода будет. Я к тому, что репозиторий на то и нужен, чтобы именно эту реализацию доступа к БД в себе и заключать и ничего лишнего имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:22 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAможно тупо IDataRecord в то, что тебе нужно отобразить в DTO ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:24 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw Код: c# 1.
Очень похоже на команду, а не на DTO. И сервис, получается, хранит весь бизнес. kmaw Код: c# 1.
Эмм... как я и говорил, ты не можешь замокать хранилище, ты мокаешь фабрику DTO, и это вообще не имеет никакого отношения к хранилищу. Вообще. С нормальным репо, я могу сделать один мок на всё хранилище, а дальше уже тестировать сервисы, тестировать проекции и прочее. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAЧтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно. Тогды прощай навигации )) ну да, в принципе можно, и это будет не много кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:28 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANADTO, Entity... Да у вас, парни, EF головного мозга :) Репозиторий может внутри себя использовать стратегию доступа к стороннему сервису, или даже сотне сервисов с разным API и форматом возвращаемых данных. Вот и подумайте, где у вас DTO, а где Entity :) Я об этом и говорю. Репо это по факту «ДАЙ-ПОЛОЖИ». Откуда он чего берёт и куда кладёт, нам фиолетово. Часть сущностей может лежать в SQL, часть в монго, часть вообще через веб-сервисы. И нам всё равно это всё фиолетово. Просто под DTO понимаются кортежи данных, нужных бизнесу. Типа мне надо на форму вывести 10 полей, или в грид собрать кортежи по 10 полей, нафига мне не упало всё остальное, для этого используются DTO. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:29 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAможно тупо IDataRecord в то, что тебе нужно отобразить в DTOЕсли Вам надо в DTO, отображайте в DTO :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttи это вообще не имеет никакого отношения к хранилищу. Вообще естественно не имеет. и не должно. это тест бизнес-логики ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... в DTOЕсли Вам надо в DTO, отображайте в DTO :) Он не понимает, что Entity это уже и есть DTO, только в контексте репо. На репо он накидывает лопатой лишнюю ответственность. Ну его право конечно, но это неправильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... в DTOЕсли Вам надо в DTO, отображайте в DTO :) давай(те) на ты. а во что это еще можно отобразить? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttи это вообще не имеет никакого отношения к хранилищу. Вообще естественно не имеет. и не должно. это тест бизнес-логики Ну так ты мочишь тут не репо, а уже бизнес-логику. А выглядит, как будто мочишь репо, хотя это не верно. Зачем создавать путанницу намерянно, я не понимать. Видимо это особый случай садо-мазохизма. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:32 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAЧтобы сильно не возиться можно тупо IDataRecord в то, что тебе нужно отобразить. Для репозитория с тремя методами Add, Get и GetAll этого будет достаточно. Тогды прощай навигации )) ну да, в принципе можно, и это будет не много кода.Указанный выше контракт и не предполагает никакой навигации. Да и какая в общем случае от неё польза? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:33 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttПросто под DTO понимаются кортежи данных, нужных бизнесу ну, это если сильно концептуально. так-то Entity - это материал для ОРМ ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:33 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Если Вам надо в DTO, отображайте в DTO :) давай(те) на ты. а во что это еще можно отобразить?Ну к примеру можно отобразить классически: в модель области определения ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:35 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawпропущено... естественно не имеет. и не должно. это тест бизнес-логики Ну так ты мочишь тут не репо, а уже бизнес-логику. А выглядит, как будто мочишь репо, хотя это не верно. Зачем создавать путанницу намерянно, я не понимать. Видимо это особый случай садо-мазохизма. где тут я мочу бизнес-логику? Код: c# 1. 2. 3. 4. 5. 6.
AccessSpecification - это уровень репозитория ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAмодель области определения это что еще за область? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAмодель области определения это что еще за область?Domain Model, так понятнее? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:39 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... это что еще за область?Domain Model, так понятнее? при использовании IDataReader - это все DTO, не более. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttПросто под DTO понимаются кортежи данных, нужных бизнесу ну, это если сильно концептуально. так-то Entity - это материал для ОРМКонцептуально ORM решает задачу преобразования объекта реального мира в форму, пригодную для сохранения в реляционной базе данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANADomain Model их просто там нет ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Domain Model, так понятнее? при использовании IDataReader - это все DTO, не более.Вообще-то Domain Model Object и DTO не одно и тоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANADomain Model их просто там нетГде там? В Вашей программе? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... ну, это если сильно концептуально. так-то Entity - это материал для ОРМКонцептуально ORM решает задачу преобразования объекта реального мира в форму, пригодную для сохранения в реляционной базе данных. ORM решает более земную задачу - Entity <-> БД ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Концептуально ORM решает задачу преобразования объекта реального мира в форму, пригодную для сохранения в реляционной базе данных. ORM решает более земную задачу - Entity <-> БДДайте определение Entity. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... при использовании IDataReader - это все DTO, не более.Вообще-то Domain Model Object и DTO не одно и тоже . а я разве обратное утверждаю? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... ORM решает более земную задачу - Entity <-> БДДайте определение Entity. ок. это отображенная в ООП-класс таблица БД ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:45 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAУказанный выше контракт и не предполагает никакой навигации. Да и какая в общем случае от неё польза? :) Удобно для корня агрегации, иначе придётся собирать агрегат по кусочкам. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Дайте определение Entity. ок. это отображенная в ООП-класс таблица БДХорошо. Пример: есть класс Person , что содержит следующий список полей: имя, список адресов и список телефонов. Как его отобразить в одну таблицу БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:49 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawгде тут я мочу бизнес-логику? вот: kmaw Код: c# 1.
репозиторий должен хранить Entity юзера (.NET представление его аналога в хранилище, т.е. по сути табличный кортеж), а UserDTO это некий срез данных, нужный сервису, UserDTO полностью абстрагируется от того, как данные лежат в хранилище, в UserDTO могут быть намапленные данные из других таблиц, например, адрес, лежащий в отдельной таблице технически, т.е. это уровень выше репы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:51 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAУказанный выше контракт и не предполагает никакой навигации. Да и какая в общем случае от неё польза? :) Удобно для корня агрегации, иначе придётся собирать агрегат по кусочкам.Не понял, почему по кусочкам? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:51 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... Удобно для корня агрегации, иначе придётся собирать агрегат по кусочкам.Не понял, почему по кусочкам? Из твоего примера выше: Person.Adresses без навигаций, придётся дополнительно дёргать адреса ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Вот примеры DTO для User-а: UserLoginDTO UserProfileDTO UserActivityDTO и т.д. в хранилище это как-то лежит в разных таблицах, корень аггрегации -- User, одна сущность, а DTO -- много, в зависимости от задач. нафига на каждый чих тащить всё в одном DTO, мне не понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 17:57 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawгде тут я мочу бизнес-логику? вот: kmaw Код: c# 1.
репозиторий должен хранить Entity юзера (.NET представление его аналога в хранилище, т.е. по сути табличный кортеж), а UserDTO это некий срез данных, нужный сервису, UserDTO п олностью абстрагируется от того, как данные лежат в хранилище , в UserDTO могут быть намапленные данные из других таблиц , например, адрес, лежащий в отдельной таблице технически, т.е. это уровень выше репы. естественно. просто тот репо который ты предлагаешь, это обертка над linq. у меня это полное скрытие ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... ок. это отображенная в ООП-класс таблица БДХорошо. Пример: есть класс Person , что содержит следующий список полей: имя, список адресов и список телефонов. Как его отобразить в одну таблицу БД? если список телефонов (он же не 1000000 записей), это коллекция которая мапится вместе с Person ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:03 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Хорошо. Пример: есть класс Person , что содержит следующий список полей: имя, список адресов и список телефонов. Как его отобразить в одну таблицу БД? если список телефонов (он же не 1000000 записей), это коллекция которая мапится вместе с PersonКуда маппится, в туже таблицу БД? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttи т.д. в хранилище это как-то лежит в разных таблицах а вот это не 100%. у DTO уже нет взаимнооднозначного отображения. DTO - это композит, там и count-ы могут лежать, и вообще дополнительные вычисленные данные ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... если список телефонов (он же не 1000000 записей), это коллекция которая мапится вместе с PersonКуда маппится, в туже таблицу БД? :) в другую. skyANA, зачем такие вопросы задаешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Куда маппится, в туже таблицу БД? :) в другую. skyANA, зачем такие вопросы задаешь?Да у вас тут терминология не пойми какая. У Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAДа у вас тут терминология не пойми какая там в начале топика схема. я понимаю Entity только как материал для ОРМ, утилитарные классы. нет ОРМ - нет Entity. а DTO всегда есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:15 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
не путать Entity-классы с сущностями в БД ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:15 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAДа у вас тут терминология не пойми какая там в начале топика схема. я понимаю Entity только как материал для ОРМ, утилитарные классы. нет ОРМ - нет Entity. а DTO всегда есть.Значит нам с тобой не по пути :) Для меня entity - это сущность, самостоятельная логическая единица, что не сводится к набору атрибутов, а характеризуется непрерывностью и индивидуальностью существования. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:18 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAа характеризуется непрерывностью и индивидуальностью существования вот такой она и лежит записями в таблицах в реляционной БД ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:21 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAа характеризуется непрерывностью и индивидуальностью существования вот такой она и лежит записями в таблицах в реляционной БД а в ОРМ-ах - просто рабочая лошадка ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAа характеризуется непрерывностью и индивидуальностью существования вот такой она и лежит записями в таблицах в реляционной БДПри чём тут реляционная БД? Нет её. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:24 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... вот такой она и лежит записями в таблицах в реляционной БДПри чём тут реляционная БД? Нет её. :) тогда и Entity нет. с сервисов приходит не энтити ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:26 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... При чём тут реляционная БД? Нет её. :) тогда и Entity нет. с сервисов приходит не энтитивот я и говорю, что нам не по пути :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... При чём тут реляционная БД? Нет её. :) тогда и Entity нет. с сервисов приходит не энтити во всяких монго тоже лежат не энтити ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawтогда и Entity нет. с сервисов приходит не энтити это пять! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... тогда и Entity нет. с сервисов приходит не энтитивот я и говорю, что нам не по пути :) skyANA, выдай свою мыслю, как надо ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:29 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Изопропилkmawтогда и Entity нет. с сервисов приходит не энтити это пять! шесть. мое определение Entity выше видел? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawkmawпропущено... тогда и Entity нет. с сервисов приходит не энтити во всяких монго тоже лежат не энтитиИсходя из твоего определения, да. Исходя из моего - наоборот. Хотя "во всяких монго" можно целиком агрегаты хранить, это да. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:32 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... вот я и говорю, что нам не по пути :) skyANA, выдай свою мыслю, как надоЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:35 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... skyANA, выдай свою мыслю, как надоЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root. молодец. а в контексте топика? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root. Вот-вот. Проблемы возникают тогда, когда ORM-овские Entity пытаются подогнать под DDD. Этим страдают даже в Microsoft. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAЯ следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root. Вот-вот. Проблемы возникают тогда, когда ORM-овские Entity пытаются подогнать под DDD. Этим страдают даже в Microsoft. это высказывание не понял ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:42 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAУ Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :) У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttпропущено... Вот-вот. Проблемы возникают тогда, когда ORM-овские Entity пытаются подогнать под DDD. Этим страдают даже в Microsoft. это высказывание не понял Погугли DDD EF или DDD NHibernate и поймёшь, и обнаружишь тонны тупикового маразма. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:46 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAУ Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :) У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того. это все так. а если нет ОРМ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:47 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttБлагодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты это не благодаря, а потому что так надо для ОРМ ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttUOW его может не быть. я думаю, что нет ОРМ, нет и его ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:49 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttпропущено... У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того. это все так. а если нет ОРМ? если ты не используешь чужую ORM, значит изобретёшь свою, при чём не важно как-то её назовешь, даже так: INoOrmDbContext... всё равно будет ORM, как не крути :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttБлагодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты это не благодаря, а потому что так надо для ОРМ вовсе нет. есть ORM, которые лишены таких возможностей под корень. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:53 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttUOW его может не быть. я думаю, что нет ОРМ, нет и его да много чего может не быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:54 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttINoOrmDbContext ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:55 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttINoOrmDbContext ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:55 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Я следую терминологии DDD. Там дано определение Entity, и Value Object, и Aggregate, и Root. молодец. а в контексте топика?В контексте топика скажу, что репозиторий по определению должен возвращать Domain Model Objects, которыми оперирует слой бизнес-логики, а не DTO. На уровне Web-сайтов и WPF приложения появляются модели представления. Но данной схемы не обязательно придерживаться всегда, надо смотреть на конкретную задачу. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 18:56 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttUOW его может не быть. я думаю, что нет ОРМ, нет и егоНу ну... Я уже давно не использую DataSet, но это таки пример реализации UoW :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAУ Хвоста Entity - это табличный кортеж, у тебя - это было давеча "отображенная в ООП-класс таблица БД". Совсем не по DDD :) У меня Entity это данные в представлении хранилища. Данные. Там не должно быть никакой логики. Благодаря ORM, Entity могут быть сложнее, чем просто набор атрибутов, они могут содержать навигационные ссылки и навигационные коллекции, чем становятся сильно похожи на агрегаты. Также Entity в контексте хранилища отвечают задачам UOW. В общем-то Entity раскрывают потенциал репозитория, но не более того.Вот опять своя доморощенная терминология :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:03 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Вот что сюда надо закинуть: микросервисы ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
а мне нравится db-repo-model-services и дальше вьюмодельки для гуя и дтошки для микросервисов. Для меня вьюмоделька это по сути дтошка, только у дтошки "гуй" - это сервис какой-нибудь, а для вьюмодельки "гуй" это, например, винформз. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:09 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAВот опять своя доморощенная терминология :) Какая ещё доморощенная терминология? В EF/NH данные отражаются в классы, которые они называют Entity. Это отнюдь не Entity из мира DDD, хоть и местами похожи, хоть и отдельные товарищи пытаются с помощью лома и такой-то матери туда втулить. Ну не получается. И как эти классы называть? POCO? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:18 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttВ EF/NH данные отражаются в классы, которые они называют Entity алилуя ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:19 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAВот опять своя доморощенная терминология :) Какая ещё доморощенная терминология? В EF/NH данные отражаются в классы, которые они называют Entity. Код: c# 1. 2. 3. 4. 5. 6.
Это Entity ? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAВот что сюда надо закинуть: микросервисы Зачем? авторУправление несогласованностями подобным образом — новый вызов для многих команд разработки, но это часто соответствует практикам бизнеса. Больше вызовов! Больше! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:24 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttВ EF/NH данные отражаются в классы, которые они называют Entity алилуяТот же вопрос: 18323769 . ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:25 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANA Код: c# 1. 2. 3. 4. 5. 6.
Это Entity ? :) Да. (вот только virtual для атрибутов, это зло, сразу видно что это в угоду NH) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:26 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANA Код: c# 1. 2. 3. 4. 5. 6.
Это Entity ? :) Да.cool hVosttвот только virtual для атрибутов, это злоА в чём зло? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:28 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Ещё нужно выяснить у камрада kmaw почему объект класса User не может существовать без реляционной БД и ORM. И почему не может в таком виде как есть храниться в MongoDB :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:32 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttвот только virtual для атрибутов, это злоА в чём зло? Потому что в угоду NH, ему нужно, чтобы он работал. А это всего лишь поле с данными, EF прекрасно работает без virtual, а в NH намудили (потому что NH -- УГ), вот и страдайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:34 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
мне думается термин дто вообще надо выкинуть из топика. Дто это вообще не про логику, не про модель, не про репозитории. Там другие названия есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... Какая ещё доморощенная терминология? В EF/NH данные отражаются в классы, которые они называют Entity. Код: c# 1. 2. 3. 4. 5. 6.
Это Entity ? :) если для ОРМ, то да. потому что их может быть похожих несколько, и они != сущностям БД ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttПотому что в угоду NH, ему нужно, чтобы он работал это нормально. потому что - это Entity ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAпропущено... А в чём зло? Потому что в угоду NH, ему нужно, чтобы он работал. А это всего лишь поле с данными, EF прекрасно работает без virtual, а в NH намудили (потому что NH -- УГ), вот и страдайте. Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий. Таки в чём зло? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:38 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.мне думается термин дто вообще надо выкинуть из топика. Дто это вообще не про логику, не про модель, не про репозитории. Там другие названия есть. Не надо выкидывать. DTO прекрасно работает с анемичной моделью, т.е. у нас есть дата-сервисы, и мы взаимодействуем с ними с помощью DTO. Например CRUD-сервисы можно сделать базовыми и они будут работать сразу для всех существующих таблиц в БД. А затем запиливать дополнительную логику в сервисах. Это стандартный путь для большинства энтерпрайзов. Вот только DDD здесь не пахнет, а это другая архитектура и гораздо меньше подходит для CRUD-базед систем. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:38 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... Потому что в угоду NH, ему нужно, чтобы он работал. А это всего лишь поле с данными, EF прекрасно работает без virtual, а в NH намудили (потому что NH -- УГ), вот и страдайте. Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий. Таки в чём зло? :) хвост ненавидит хибернейт. а ненависть - это зло ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:40 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANA Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий. Таки в чём зло? :) Эти классы -- не POCO. Какие ещё аргументы нужны? Для virtual полей допустимо иметь в классе 2 значения: заданное, и прокси-значение. Это не просто зло, это ахтунг полнейший. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:42 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий. Таки в чём зло? :) хвост ненавидит хибернейт. а ненависть - это злоТы это от ответа не увиливай: 18323802 :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawхвост ненавидит хибернейт. а ненависть - это зло Я не ненавижу, я его презираю. Он своё отжил. Да, было время, когда EF был кособокий и кривой. Но щас пора брать лопату и закапывать NH глубоко. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANA Зло - понятие нравственности, противоположное понятию добра, означает намеренное, умышленное, сознательное причинение кому-либо вреда, ущерба, страданий. Таки в чём зло? :) Эти классы -- не POCO. Какие ещё аргументы нужны?Как какие? Доказывающие то, что это причиняет кому-либо вред, ущерб, страдания :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawхвост ненавидит хибернейт. а ненависть - это зло Я не ненавижу, я его презираю. Он своё отжил. Да, было время, когда EF был кособокий и кривой. Но щас пора брать лопату и закапывать NH глубоко.Да, пора переходить на Dapper и микросервисы :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:45 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAЕщё нужно выяснить у камрада kmaw почему объект класса User не может существовать без реляционной БД и ORM. И почему не может в таком виде как есть храниться в MongoDB :) так я от ответа и не увиливаю. это опять DTO. еще раз: нет ОРМ - нет Entity ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:45 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, DTO - УГ, потому, что нет однозначной Логики отображения ДТО на Модель В ВИПРОС есть Частичное представление Макротипа с четкой логикой отображения ВИПРОС может автоматически сгенерировать всевозможные Частичные представления макротипа (но лучше все ж создать по отдельности, так как всевозможных генерируется дофига :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:45 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAКак какие? Доказывающие то, что это причиняет кому-либо вред, ущерб, страдания :) Хм. А если бы NH требовал, чтобы любые примитивные значения можно было определять только через специальные обёртки? Код: c# 1. 2. 3. 4. 5. 6.
норм? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:46 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawнет ОРМ - нет Entity Не верный ответ. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:46 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи остальная мишура - технические костыли ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:47 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAДа, пора переходить на Dapper и микросервисы :) Совсем? EF 7 смотрел? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:47 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosDTO - УГ, потому, что нет однозначной Логики отображения ДТО на Модель Есть. Это конфигурация проекции. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw, надо сначала определиться - что такое ентити и нафига ему ОРМ какой то ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, по моему пониманию дто работает прекрасно с любой моделью в любом виде. Так как это по сути просто контракт сервиса "в последней инстанции". Данные обрабатываются логикой в любом виде и экспозятся через сервисы куда угодно. Но то что "с той стороны" сервисов - уже не релевантно по сути к вопросу доступа к данным и их обработке. А, как я понимаю, именно это тут и обсуждается в первую очередь. То есть я считаю что дто это передача данных во внешнюю подсистему\систему. Даже если она живет в том же процессе, если мы сказали дто, значит данные пошли в другой домен. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRoshVostt, ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи остальная мишура - технические костыли Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:49 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosчто такое ентити Ентити определяется идентификатором (Id, Uid, Guid...). Два объекта с одинаковым идентификатором считаются равными, без сравнения их содержимого. Это Entity. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:50 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRosDTO - УГ, потому, что нет однозначной Логики отображения ДТО на Модель Есть. Это конфигурация проекции. покажи пример (Проекция - это метаданные, подмножество метаданных макротипа. Не всегда возможно Проекция, так как Проекция накладывает доп ограничения на целостность макротипа - нужны значения по умолчанию как минимум, если например, Проекция редактируема и т.д.) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:51 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.А, как я понимаю, именно это тут и обсуждается в первую очередь это Вам и мне понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, значит ентити ваш - Объект с лайфтаймом (коллекция) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRoshVostt, ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи остальная мишура - технические костыли Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA). это про проекции был вопрос, при чем тут слой презентации ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:53 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRoshVostt, ты лучше дальше понятия Проекция (если я правильно тебя понимаю, то это ВИПРОСовские частичные представления) не отходи остальная мишура - технические костыли Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA). Частичное представление - это Точка зрение на Модель определенной Роли (Актора) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:54 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
"нет ОРМ - нет Entity" =нет объектно реляционного мапера - нет энтити если мы натравливаем ef не на базу, а на xml файл, не меняя код, просто меняя источник данных, энтити исчезают? Таким образом невозможно знать есть энтити или нет, не видя connectionstring, так выходит? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:54 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis., ОРМ разные, есть например расшифровка - Объект Роле Моделинг ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:55 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRoshVosttпропущено... Частичное представление это уже слой презентации, он кстати вполне может быть завязан на DTO (минуя дополнительные классы, типа вью-моделей, что хорошо для SPA). Частичное представление - это Точка зрение на Модель определенной Роли (Актора) в контексте тоgика - джоин проекция и where. которые хвост хочет видеть в датасервисах ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:56 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.если мы натравливаем ef не на базу, а на xml файл, не меняя код, просто меняя источник данных, энтити исчезают? для терминологической чистоты - да ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:57 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosпокажи пример (Проекция - это метаданные, подмножество метаданных макротипа. Не всегда возможно Проекция, так как Проекция накладывает доп ограничения на целостность макротипа - нужны значения по умолчанию как минимум, если например, Проекция редактируема и т.д.) Код: c# 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:57 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosзначит ентити ваш - Объект с лайфтаймом (коллекция) Это что угодно с идентификатором. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:57 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawэто про проекции был вопрос, при чем тут слой презентации Слово «представление» прозвучало. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRosпокажи пример (Проекция - это метаданные, подмножество метаданных макротипа. Не всегда возможно Проекция, так как Проекция накладывает доп ограничения на целостность макротипа - нужны значения по умолчанию как минимум, если например, Проекция редактируема и т.д.) Код: c# 1. 2.
и где это должно находиться? правильно - в репозитории ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw, давно пора этот "контекст" выбросить ОРМ в смысле Объект Релейшн Маппинг - узкая тема и о не й по хорошему воще ничего не должно быть известно программисту, так глубоко это техническое решение должно прятаться ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosЧастичное представление - это Точка зрение на Модель определенной Роли (Актора) Ээмм.. кортеж -- чем не подходит? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, кортеж не содержит в себе информациь - откуда он есть пошло и кому чего должен ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:59 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosи о не й по хорошему воще ничего не должно быть известно программисту оно и так глубоко, рядом с репозиториями и Entity ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 19:59 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAЕщё нужно выяснить у камрада kmaw почему объект класса User не может существовать без реляционной БД и ORM. И почему не может в таком виде как есть храниться в MongoDB :) так я от ответа и не увиливаю. это опять DTO. еще раз: нет ОРМ - нет Entityno comments ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:00 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw, если бы блыло глубок то никаких разговоров кроме "ентити" не должно было быть ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawи где это должно находиться? правильно - в репозитории репозитарий тут при чём? репозитарию фиолетово на бизнес-логику, чё и кому нужно. он предоставляет доступ в хранилище, а что конкретно ты будешь из него брать и как с этим работать -- не его дело, поэтому ни про какие DTO ему знать не надо, иначе пухнет ответственность. репозиторий вообще может использоваться в разных модулях и даже приложения, один репозиторий -- куча клиентов. и чё теперь, ему для всех надо кучу DTO хранить? идиотизм высшей пробы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRoshVostt, кортеж не содержит в себе информациь - откуда он есть пошло и кому чего должен именно! затем он и полезен, что это чистый кортеж, без меты и логики. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:02 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAКак какие? Доказывающие то, что это причиняет кому-либо вред, ущерб, страдания :) Хм. А если бы NH требовал, чтобы любые примитивные значения можно было определять только через специальные обёртки? Код: c# 1. 2. 3. 4. 5. 6.
норм? Тогда бы можно было говорить о намеренном причинении страданий :) Но такого нет, значит и зла нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:03 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRoskmaw, если бы блыло глубок то никаких разговоров кроме "ентити" не должно было быть это потому что, не только лишь все могут его спрятать в DAL, и говорят, что это нормально. я считаю, что это не нормально ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:03 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAДа, пора переходить на Dapper и микросервисы :) Совсем? EF 7 смотрел?Не смотрел. А что там смотреть-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:04 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAТогда бы можно было говорить о намеренном причинении страданий :) Но такого нет, значит и зла нет. о как. а теперь факт: Код: c# 1. 2. 3. 4. 5. 6.
как думаешь, может ли быть такая ситуция с NHibernate, когда _id == 1, а Id == 0 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:05 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttрепозитарию фиолетово на бизнес-логику ему и так на неё фиолетово. моделируем ситуацию, что-то хранится в JS. и что, передавать/возвращать в репозиторий JS, ведь там хранится JS? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAНе смотрел. А что там смотреть-то? Зря. Смотри как развивается, поддержку NoSQL смотри ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.hVostt, по моему пониманию дто работает прекрасно с любой моделью в любом виде. Так как это по сути просто контракт сервиса "в последней инстанции". Данные обрабатываются логикой в любом виде и экспозятся через сервисы куда угодно. Но то что "с той стороны" сервисов - уже не релевантно по сути к вопросу доступа к данным и их обработке. А, как я понимаю, именно это тут и обсуждается в первую очередь. То есть я считаю что дто это передача данных во внешнюю подсистему\систему. Даже если она живет в том же процессе, если мы сказали дто, значит данные пошли в другой домен.Вы практически дали классическое определение понятию DTO. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttрепозитарию фиолетово на бизнес-логику ему и так на неё фиолетово. моделируем ситуацию, что-то хранится в JS. и что, передавать/возвращать в репозиторий JS, ведь там хранится JS? ему не фиолетово, он должен знать какие DTO кому нужны. ну или тебе заняться больше в этой жизни нечем и ты продублировал для каждого Entity по DTO. молодец чё сказать. я был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRoshVostt, кортеж не содержит в себе информациь - откуда он есть пошло и кому чего должен именно! затем он и полезен, что это чистый кортеж, без меты и логики. да ничем он не полезен (кроме тех случаев, когда модель в башке прогера и в коде размазан) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAТогда бы можно было говорить о намеренном причинении страданий :) Но такого нет, значит и зла нет. о как. а теперь факт: Код: c# 1. 2. 3. 4. 5. 6.
как думаешь, может ли быть такая ситуция с NHibernate, когда _id == 1, а Id == 0 ? ты про прокси? там там могут быть и другие страдания ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:08 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttя был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел а что такого беспредельного? зато архитектурная ясность. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:10 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawты про прокси? там там могут быть и другие страдания я прокси только приемлю для Lazy-load, но никак не для чухни типа отслеживания изменений. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:10 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRosчто такое ентити Ентити определяется идентификатором (Id, Uid, Guid...). Два объекта с одинаковым идентификатором считаются равными, без сравнения их содержимого. Это Entity.Тут надо уточнить, что идентификация может быть и естественной. Даже скажу так: от неё и надо плясать. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:10 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttя был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел а что такого беспредельного? зато архитектурная ясность. никакой ясности, бесполезное дублирование. что за маниакальная страсть -- скрыть Entity? есть хоть какие-то предпосылки для подобной деятельности? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:10 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawты про прокси? там там могут быть и другие страдания я прокси только приемлю для Lazy-load, но никак не для чухни типа отслеживания изменений. это гибкая весчь. скоро и в EF так будет ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:11 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawэто гибкая весчь. скоро и в EF так будет В EF уже сто лет так. И лейзи есть, и отслеживание изменений. И полная поддержка POCO, чего хиберу не снилось. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttбесполезное дублирование ТС, кстати, тоже вложил этот посыл ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:13 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawэто гибкая весчь. скоро и в EF так будет В EF уже сто лет так. И лейзи есть, и отслеживание изменений. И полная поддержка POCO, чего хиберу не снилось. Еще бы коллекции прятать. Хотя бы за IEnumerable ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:14 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttViPRosзначит ентити ваш - Объект с лайфтаймом (коллекция) Это что угодно с идентификатором.Я б всё таки сказал, что обладает уникальностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:15 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.hVosttпропущено... В EF уже сто лет так. И лейзи есть, и отслеживание изменений. И полная поддержка POCO, чего хиберу не снилось. Еще бы коллекции прятать. Хотя бы за IEnumerable да лана, коде ферст запилили, дальше все как у хибера будет ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:16 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... Это что угодно с идентификатором.Я б всё таки сказал, что обладает уникальностью. Ну а на практике это -- с идентификатором ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:16 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.Еще бы коллекции прятать. Хотя бы за IEnumerable Нафига??? Я долго пытался выяснить у одного коллеги из другой команды, в чём зло IQueryable<>, но так и не услышал ничего кроме «плохо и всё!!!» ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:18 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, ну потому что я не могу замапить икверибл. Нужен иколлекшн. А значит в нем есть метод адд. А значит я не могу, например, сделать нормальную валидацию на добавление. Типа, у меня есть метод Add(), а рядом лежит иколекшн с котором я делаю что хочу... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:22 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis., а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:24 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.hVostt, ну потому что я не могу замапить икверибл. Нужен иколлекшн. А значит в нем есть метод адд. А значит я не могу, например, сделать нормальную валидацию на добавление. Типа, у меня есть метод Add(), а рядом лежит иколекшн с котором я делаю что хочу... Всё правильно. Именно поэтому Entity из мира EF/NH никак не тянет на Domain Object. А попытки запилить DO через интерфейс жалки и унылы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:25 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAпропущено... Я б всё таки сказал, что обладает уникальностью. Ну а на практике это -- с идентификатором Вот так вот и кладут болт на теорию 1. Идентификация часто естественная: имя, фамилия, номер паспорта; 2. Когда проектируешь систему, что работает с хотя бы дестяком сторонних поставщиков и потребителей, в каждом из которых сущность идентифицируется по-разному, то думаешь шире, а не "что угодно с Id". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttв чём зло IQueryable<> тем что датаконтектст переходит в сервисы? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVostt, и да и нет, с одной стороны они унылы, с другой уже приват сетеры появились. То-ли еще будет) Я раньше так не делал, а вот, недавно сделал, и знаешь, мне на самом деле нравится. Конечно есть ряд отвратительных моментов, но вполне с ними можно мериться. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:28 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.Denis., а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное)Особенно когда для источника данных никто за вас не реализовал икверибл провайдер :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:28 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANADenis.Denis., а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное)Особенно когда для источника данных никто за вас не реализовал икверибл провайдер :) какой прок от него, когда запрос на SQL ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttя был бы недоволен, если бы в моей команде кто-то тратил время на подобный беспредел а что такого беспредельного? зато архитектурная ясность. прально мыслишь, все что касается модели, должна явно определяться в модели, в виде структуры или поведения ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANA, ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусь ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttв чём зло IQueryable<> тем что датаконтектст переходит в сервисы?Оп, вот уже и репозиторий удалился. Сервисы работают с репозиториями, то есть ничего не знают ни про EF-ский датаконтекст, ни про NH-скую сессию, ни про Mongo-вский клиент. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.Denis., а икверибл я наоборот люблю. Сейчас всегда только "дырявые" репозитории и делаю. Гораздо удобнее чем ienumerable. В конечном итоге проще и быстрее писать, а не это ли главное) Я исхожу из следующей суперпозиции: 1. Тестируемость. 2. Сопровождаемость. 3. Понятность. 4. Удобство дальнейшей разработки. Конечно, круто запилить 10 слоёв абстракций и тысячи мелких классов-спецификаций/команд/ивентов... Это очень круто! Прям медаль большая позолоченная так и просится на грудь архитектору года. Но если с этим работать тяжело, если новичок в команде будет въезжать в эту муть неделю, то в топку. Нафиг. Отправили чувака с медалью на конференцию, и пусть он там потеряется. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:31 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусь ой, не зарекайтесь. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:32 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.skyANA, ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусьЧто из области фантастики? Я работал с вполне реальными системами онлайн-бронирования :) Покажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:33 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... тем что датаконтектст переходит в сервисы?Оп, вот уже и репозиторий удалился. Сервисы работают с репозиториями, то есть ничего не знают ни про EF-ский датаконтекст, ни про NH-скую сессию, ни про Mongo-вский клиент. а какже они там что-то потом джоинят? проекции делают? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:33 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Особенно когда для источника данных никто за вас не реализовал икверибл провайдер :) какой прок от него, когда запрос на SQLОт кого от него? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:34 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAВот так вот и кладут болт на теорию Теория без практики -- ноль без палочки. skyANA1. Идентификация часто естественная: имя, фамилия, номер паспорта; Угу, выскочила девушка замуж и слетела идентификация. Сменил паспорт из-за утери, слетела идентификация. Это же уже сто пицот раз измусоленный вдоль и поперёк вопрос! Начиналось всё с красивой сказки, с натуральных идентификаторов. И где они сейчас? skyANA2. Когда проектируешь систему, что работает с хотя бы дестяком сторонних поставщиков и потребителей, в каждом из которых сущность идентифицируется по-разному, то думаешь шире, а не "что угодно с Id". Что угодно с Id. Данные из сторонних систем связываются таким образом: <Их ID>—<Наш ID>. Да, <их ID> может быть комплексным, а у нас в единой системе — нет. Точнее, могло бы быть... Но нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:35 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANADenis.skyANA, ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусьЧто из области фантастики? Я работал с вполне реальными системами онлайн-бронирования :) Покажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :) нет, я имел ввиду, конечно, репозиторий на базу. Для внешних систем, конечно, плохой вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:35 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Оп, вот уже и репозиторий удалился. Сервисы работают с репозиториями, то есть ничего не знают ни про EF-ский датаконтекст, ни про NH-скую сессию, ни про Mongo-вский клиент. а какже они там что-то потом джоинят? проекции делают?Вопросы какие-то нелепые начались. Где там и кто кого джойнит? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttв чём зло IQueryable<> тем что датаконтектст переходит в сервисы? Не переходит. Ты не можешь изменить набор данных через IQueryable<>. Ни добавить, ни удалить. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... а какже они там что-то потом джоинят? проекции делают?Вопросы какие-то нелепые начались. Где там и кто кого джойнит? http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1181398&msg=18323043 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAОсобенно когда для источника данных никто за вас не реализовал икверибл провайдер :) Это ж вызов! Challenge! Почему нет-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:37 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.skyANA, ну это из области фантастики. Много раз слышал "а что если базу менять", "а что если на хибер переходить", но ни раз не сталкивался и вряд ли столкнусь Я сталкивался. И не раз. Переходили и на Postgres с MS SQL, и хибер выпиливали в пользу EF. Так что... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:38 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ну, чувствую, что народ уже набрал определенный багаж и готов критически осмыслить "технологии" значит жди в скорости крутых обновлений в "технологиях" - засиделись фулеры, пора народ вернуть к нулю - боднию с биндингами и хамлами (а как там комбобокс забиндить?), всякими там енумерейбле, хренейбле :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:40 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAОсобенно когда для источника данных никто за вас не реализовал икверибл провайдер :) Это ж вызов! Challenge! Почему нет-то? А для на фига козе баян, если конкретный API, что в сто раз уже возможностей икверибла? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:40 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAПокажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :) Дык профит же очевиден. Один раз провайдер реализовать, чем сто-пицот разных отдельных спецификаций или ещё хуже, методов в репозитории. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAПокажите мне реализацию икверибл провайдера к какому-нибудь амадеусу :) Дык профит же очевиден. Один раз провайдер реализовать, чем сто-пицот разных отдельных спецификаций или ещё хуже, методов в репозитории.Каким это образом один раз? Если у Амадеуса один API, у Куони второй, у Травко третий и т.д.? :) Или давай поверх них сначала навернём абстракций, да? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAА для на фига козе баян, если конкретный API, что в сто раз уже возможностей икверибла? :) Странный вопрос. IQueryable -- стандарт для мира дотнета, а какой-то конкретный АПИ нет. А зачем СУБД реализуют SQL? Надо было каждому вендуру свой язык выдумать, ни разу не похожий ни на чей другой. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAКаким это образом один раз? Если у Амадеуса один API, у Куони второй, у Травко третий и т.д.? :) Или давай поверх них сначала навернём абстракций, да? Каждому по провайдеру и дело в шляпе. Сделали и забыли. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Вопросы какие-то нелепые начались. Где там и кто кого джойнит? http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1181398&msg=18323043 Давайте обратимся к определению Data Transfer Object (Объект передачи данных) . ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:46 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAА для на фига козе баян, если конкретный API, что в сто раз уже возможностей икверибла? :) Странный вопрос. IQueryable -- стандарт для мира дотнета, а какой-то конкретный АПИ нет. А зачем СУБД реализуют SQL? Надо было каждому вендуру свой язык выдумать, ни разу не похожий ни на чей другой.А зачем есть DSL? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:47 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANA, это полная хрень (техническое решение) какого то тупого чека ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAА зачем есть DSL? Ну так об этом и речь. Реализуешь провайдер и можешь юзать единый DSL (LINQ). А ты что предлагаешь? Провайдер тяжело тип реализовывать, вместо этого лучше... что? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:49 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAКаким это образом один раз? Если у Амадеуса один API, у Куони второй, у Травко третий и т.д.? :) Или давай поверх них сначала навернём абстракций, да? Каждому по провайдеру и дело в шляпе. Сделали и забыли.Ну в итоге так и получается. Только не по икверибл провайдеру :) А по реализации своего провайдера с нужным в этой предметной области интерфейсом. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:49 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosskyANA, это полная хрень (техническое решение) какого то тупого чекаЧего? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:50 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAНу в итоге так и получается. Только не по икверибл провайдеру :) А по реализации своего провайдера с нужным в этой предметной области интерфейсом. Эмм.. никто не отменяет интерфейса для предметной области. Я только про запросы к данным из коллекции говорю, низкого уровня. Уберём IQueryable и заменим на некий универсальный транслятор domainSQL и по сути получим тоже самое. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:51 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAА зачем есть DSL? Ну так об этом и речь. Реализуешь провайдер и можешь юзать единый DSL (LINQ). А ты что предлагаешь? Провайдер тяжело тип реализовывать, вместо этого лучше... что?Вообще-то я о том, что есть языки общено назначения, а есть DSL. С намёком на то, что для конкретной задачи, в конкретной предметной области не надо стремиться реализовывать всю полноту возможностей икверибла :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
когда строишь мир свой, обычно какие то вещи невозможно соорудить непротиворечиво и красиво - так как аксиомы неверные вот тут то начинаются троица там бл* дух зачем то приперся а тут папашу с сыном никак не идентифицировать дальше пошли бабы, ипостолы, папы, попы и всякая иная нечисть вот ДТО это типа Попа :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAВообще-то я о том, что есть языки общено назначения, а есть DSL. С намёком на то, что для конкретной задачи, в конкретной предметной области не надо стремиться реализовывать всю полноту возможностей икверибла :) А, с этим согласен. Всю полноту не всегда возможно будет реализовать, например, агрегацию или подзапросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:53 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAНу в итоге так и получается. Только не по икверибл провайдеру :) А по реализации своего провайдера с нужным в этой предметной области интерфейсом. Эмм.. никто не отменяет интерфейса для предметной области. Я только про запросы к данным из коллекции говорю, низкого уровня. Уберём IQueryable и заменим на некий универсальный транслятор domainSQL и по сути получим тоже самое.Хм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:55 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosкогда строишь мир свой, обычно какие то вещи невозможно соорудить непротиворечиво и красиво - так как аксиомы неверные вот тут то начинаются троица там бл* дух зачем то приперся а тут папашу с сыном никак не идентифицировать дальше пошли бабы, ипостолы, папы, попы и всякая иная нечисть вот ДТО это типа Попа :)Если рассматривать DTO в рамках данного определения , то никой попы не наблюдается. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:57 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable? А почему нет? Код: c# 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 20:59 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANA, я как раз посмотрел и потому написал тот пост если чек не удосужился понять, что в два чека это мир видя по разному!! то он хотя бы должен был ввести Понятие - Трансформация моделей (со всеми вытекающими), а не фигню, что в голову пришло для залатания устройства своего мирка ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable? да. так проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:02 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable? А почему нет? Код: c# 1. 2.
Ну потому как expression тут лишнее. Как и OData. Мы имеем сильно ограниченный набор фильтров (условий, критериев поиска), что легко выражаются объектами предметной области. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:41 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Denis.skyANAХм, если поиск перелёта из Москвы в Барселону происходит в локальной базе туроператора, то IQueryable, а если ещё и по сервисам его партнёров, то уже не IQueryable? да. так проще.Чем же это проще? Проще чего? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:43 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
ViPRosskyANA, я как раз посмотрел и потому написал тот пост если чек не удосужился понять, что в два чека это мир видя по разному!! то он хотя бы должен был ввести Понятие - Трансформация моделей (со всеми вытекающими), а не фигню, что в голову пришло для залатания устройства своего миркаДавай конкретнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:44 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAНу потому как expression тут лишнее. Как и OData. OData лишь для примера. А expression отлично выражает мысль при запросе данных в .NET, почему лишнее? Ну будет не expression, а какой-то кастомный способ для запроса данных, т.е. ты попросту плодишь новые сущности: интерфейсы там, где этого можно было бы избежать. skyANAМы имеем сильно ограниченный набор фильтров (условий, критериев поиска), что легко выражаются объектами предметной области. Да ради бога. Только твою предметную область может слопать лишь ограниченное количество потребителей, высокий уровень связности. Вот для примера. Мы решили применить новый набор контролов. Он кушает IQueryable, потому что разработчики контролов понятия не имеют о твоих предметных областях, и не должны. А так как у нас повсюду IQueryable, мы просто скормили их и оставшееся время посвятили другим задачам. В ином случае нам бы пришлось пилить целую армию адаптеров, на что просто убили бы много времени. Это просто для примера, его можно покритиковать, типа а нафига мы будем брать какие-то контролы, мы свои запилим, под свои интерфейсы. Ну-ну... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAВопросы какие-то нелепые начались. да просто вы с хвостом начали флудить ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 21:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAВопросы какие-то нелепые начались. да просто вы с хвостом начали флудить Да нет, мы всё выяснили. Ты тупо запилил для кучи Entity классов их дублёры DTO, чтобы эээ... спрятать Entity, иного объяснения я не вижу. Не понятно чё в таком случае тут делают дата-сервисы, вся бизнес логика осела в репозитории. В общем смешались в кучу кони, люди.. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAViPRosкогда строишь мир свой, обычно какие то вещи невозможно соорудить непротиворечиво и красиво - так как аксиомы неверные вот тут то начинаются троица там бл* дух зачем то приперся а тут папашу с сыном никак не идентифицировать дальше пошли бабы, ипостолы, папы, попы и всякая иная нечисть вот ДТО это типа Попа :)Если рассматривать DTO в рамках данного определения , то никой попы не наблюдается. а кто его по-другому рассматривает? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:01 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAНу потому как expression тут лишнее. Как и OData. OData лишь для примера. А expression отлично выражает мысль при запросе данных в .NET, почему лишнее? Ну будет не expression, а какой-то кастомный способ для запроса данных, т.е. ты попросту плодишь новые сущности: интерфейсы там, где этого можно было бы избежать. skyANAМы имеем сильно ограниченный набор фильтров (условий, критериев поиска), что легко выражаются объектами предметной области. Да ради бога. Только твою предметную область может слопать лишь ограниченное количество потребителей, высокий уровень связности. Вот для примера. Мы решили применить новый набор контролов. Он кушает IQueryable, потому что разработчики контролов понятия не имеют о твоих предметных областях, и не должны. А так как у нас повсюду IQueryable, мы просто скормили их и оставшееся время посвятили другим задачам. В ином случае нам бы пришлось пилить целую армию адаптеров, на что просто убили бы много времени. Это просто для примера, его можно покритиковать, типа а нафига мы будем брать какие-то контролы, мы свои запилим, под свои интерфейсы. Ну-ну...Эххх... Мою предметную область могут слопать решения на PHP, Java, Ruby и т.д. Как же у них это получится, когда нету там IQueryable? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:05 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttвся бизнес логика осела в репозитории Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Код: 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.
где тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппинг ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Если рассматривать DTO в рамках данного определения , то никой попы не наблюдается. а кто его по-другому рассматривает?Ты. По-своему :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... а кто его по-другому рассматривает?Ты. По-своему :) это тебе так кажется ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:08 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawhVosttвся бизнес логика осела в репозитории Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Код: 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.
где тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппингАдъ :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:09 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Код: 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.
где тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппингАдъ :) почему? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:10 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Ты. По-своему :) это тебе так кажетсяНе кажется. У меня от смены хранилища понятия не меняются :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... это тебе так кажетсяНе кажется. У меня от смены хранилища понятия не меняются :) у меня тоже ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Не кажется. У меня от смены хранилища понятия не меняются :) у меня тожеНу-ну... Хранили в РСУБД, использовали ORM, User был entity. Стали хранить в MongoDB и User стал DTO :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:16 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Адъ :) почему?У тебя в одну сторону маппинг в одну строку, в обратную в 20. При этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:20 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAУ тебя в одну сторону маппинг в одну строку, в обратную в 20. это фигня ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:22 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAПри этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости. поясни, плиз ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
И ещё. Для на фига метод Save возвращает объект того же типа, что и получает на вход? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:49 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAУ тебя в одну сторону маппинг в одну строку, в обратную в 20. это фигняНу ну... А в чём вообще смысл InfoSystemDTO? Тупо проекция? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAИ ещё. Для на фига метод Save возвращает объект того же типа, что и получает на вход? потому что из БД запрашивает. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:53 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... это фигняНу ну... А в чём вообще смысл InfoSystemDTO? Тупо проекция? тупо да ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:54 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmaw, он и не может быть ничем иным ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 22:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAПри этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости. skyANA, это ты про что? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:04 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAИ ещё. Для на фига метод Save возвращает объект того же типа, что и получает на вход? потому что из БД запрашивает.Чего? Это получается, что любой другой разработчик, кто хочет использовать твой репозиторий, должен быть в курсе нюансов его реализации? Оказывается метод Save не просто сохраняет состояние объекта в том виде, в каком оно есть, но ещё что-то из БД запрашивает. А если хранилище изменилось, то это "запрашивает" тоже реализовывать надо? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:04 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAПри этом уже используя ORM ты сверху зачем-то харкодишь правило transient-ости. skyANA, это ты про что?Про Id > 0. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:05 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... потому что из БД запрашивает.Чего? Это получается, что любой другой разработчик, кто хочет использовать твой репозиторий, должен быть в курсе нюансов его реализации? Оказывается метод Save не просто сохраняет состояние объекта в том виде, в каком оно есть, но ещё что-то из БД запрашивает. А если хранилище изменилось, то это "запрашивает" тоже реализовывать надо? а что там реализовывать-то. всю реализацию уже привел выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:06 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAА если хранилище изменилось, то это "запрашивает" тоже реализовывать надо? конечно ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:07 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAА если хранилище изменилось, то это "запрашивает" тоже реализовывать надо? конечноКлассный контракт! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:08 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... skyANA, это ты про что?Про Id > 0. тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так. подскажи как правильно ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Про Id > 0. тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так. подскажи как правильноИспользовать средства ORM, раз уж используешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:18 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так. подскажи как правильноИспользовать средства ORM, раз уж используешь. skyANAkmawпропущено... тут, сложно. с одной стороны вроде говнокод, но там всякие нулл/не нулл. проще так. подскажи как правильноИспользовать средства ORM, раз уж используешь. вот это лишнее? Код: c# 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:22 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAЭххх... Мою предметную область могут слопать решения на PHP, Java, Ruby и т.д. Как же у них это получится, когда нету там IQueryable? :) Ты какую-то фигню говоришь. При чём тут PHP? Я говорю про интерфейсы внутри NET, ты пихаешь мне PHP. Так-то твою предметную область никто не слопает. А если ты реализуешь OData, то получишь и IQueryable и лопать может кто угодно, хоть PHP, хоть Java, хоть упоротый чёрт на куличах. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:22 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Использовать средства ORM, раз уж используешь. skyANAпропущено... Использовать средства ORM, раз уж используешь. вот это лишнее? Код: c# 1.
Судя по коду, да. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:24 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawгде тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппинг вижу кусок бизнеса, а не маппинг. маппинг реализуется на Automapper, и при чём двух-сторонний, а у тебя односторонний. и профита не вижу, и вообще это жесть адская. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:24 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttkmawгде тут "бизнес логика осела в репозитории"? маппинг? так маппинг это не бизнес-логика - это маппинг вижу кусок бизнеса, а не маппинг. маппинг реализуется на Automapper, и при чём двух-сторонний, а у тебя односторонний. и профита не вижу, и вообще это жесть адская. где кусок бизнеса ты видешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:25 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... пропущено... вот это лишнее? Код: c# 1.
Судя по коду, да. это всё игра в прятки с ORM/Entity =) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:26 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawгде кусок бизнеса ты видешь? if..else..Version++, кроме того Save сидит здесь, с какого перепугу? это уже бизнес, он отвечает за то, когда именно надо данные сохранить в контексте бизнес-транзакции. в общем, всё переделать. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAkmawпропущено... пропущено... вот это лишнее? Код: c# 1.
Судя по коду, да. т.е. при наличии Id > 0 все равно можно Код: c# 1.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAЭххх... Мою предметную область могут слопать решения на PHP, Java, Ruby и т.д. Как же у них это получится, когда нету там IQueryable? :) Ты какую-то фигню говоришь. При чём тут PHP? Я говорю про интерфейсы внутри NET, ты пихаешь мне PHP. Так-то твою предметную область никто не слопает. А если ты реализуешь OData, то получишь и IQueryable и лопать может кто угодно, хоть PHP, хоть Java, хоть упоротый чёрт на куличах.Какую ещё фигню? Ты же позиционируешь IQueryable как некую фишку для каких-то там потребителей. А на практике конкуренты могут отжать часть ниши без твоих заморочек. Реализовав ограниченный предметной областью API. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:28 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttкроме того Save сидит здесь так он в транзакции. а она в сервисе. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
А про контролы, заточенные только под икверибл, я вообще молча смеюсь :) Особенно под мобилу UI Kit-ы так все сплошь и рядом на икверибл заточены :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:30 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAКакую ещё фигню? Ты же позиционируешь IQueryable как некую фишку для каких-то там потребителей. А на практике конкуренты могут отжать часть ниши без твоих заморочек. Реализовав ограниченный предметной областью API. И чем же плох IQueryable, как часть API? Никакая это не фишка, это конкретный интерфейс и LINQ — сегодня стандарт де-факто в мире .NET. Его можно использовать больше, чем средство для работы с коллекциями и ORM. Он сериализуется и десериализуется, что открывает путь «наружу» в твои любимые руби и питоны. Что ещё надо? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:32 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
kmawskyANAпропущено... Судя по коду, да. т.е. при наличии Id > 0 все равно можно Код: c# 1.
?Хм... Я конечно EF не использую, но вроде как там Attach к контексту выполнить можно не только через Find :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:33 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAКакую ещё фигню? Ты же позиционируешь IQueryable как некую фишку для каких-то там потребителей. А на практике конкуренты могут отжать часть ниши без твоих заморочек. Реализовав ограниченный предметной областью API. И чем же плох IQueryable, как часть API? Никакая это не фишка, это конкретный интерфейс и LINQ — сегодня стандарт де-факто в мире .NET. Его можно использовать больше, чем средство для работы с коллекциями и ORM. Он сериализуется и десериализуется, что открывает путь «наружу» в твои любимые руби и питоны. Что ещё надо?Ничем не плох и не хорош. Много времени только на него зря тратить. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:34 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAAttach к контексту вот за это спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAА про контролы, заточенные только под икверибл, я вообще молча смеюсь :) Особенно под мобилу UI Kit-ы так все сплошь и рядом на икверибл заточены :) Серверные реализации да. Чоб нет-то? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:36 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAА про контролы, заточенные только под икверибл, я вообще молча смеюсь :) Особенно под мобилу UI Kit-ы так все сплошь и рядом на икверибл заточены :) Серверные реализации да. Чоб нет-то?По статистике в серверной реализации лидирует PHP. Подо что больше будут писать контролы? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2015, 23:52 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAПо статистике в серверной реализации лидирует PHP. Подо что больше будут писать контролы? :) Вот ты прицепился к этому PHP, хрен отцепишь. Какая нафиг разница какие там позиции в мире занимает PHP? Что это меняет? Типа контролов под дотнетов нет? Открою великую тайну: есть и хватает! Мне этот PHP задаром не упал, совершенно наплевать что там и как там в мире PHP совершенно. Мне не платят за разработку PHP, я не учился и не практиковался на PHP, и даже малейшего желания не испытываю. Абсолютное большинство разработчиков .NET сидят в энтерпрайзе, и я тоже, а в энтерпрайзе никакими PHP даже не пахнет. Так зачем говорить PHP-PHP-PHP? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 01:27 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAПо статистике в серверной реализации лидирует PHP. Подо что больше будут писать контролы? :) Вот ты прицепился к этому PHP, хрен отцепишь. Какая нафиг разница какие там позиции в мире занимает PHP? Что это меняет? Типа контролов под дотнетов нет? Открою великую тайну: есть и хватает! Мне этот PHP задаром не упал, совершенно наплевать что там и как там в мире PHP совершенно. Мне не платят за разработку PHP, я не учился и не практиковался на PHP, и даже малейшего желания не испытываю. Абсолютное большинство разработчиков .NET сидят в энтерпрайзе, и я тоже, а в энтерпрайзе никакими PHP даже не пахнет. Так зачем говорить PHP-PHP-PHP? Ты включил дурака типа? Ну ладно, тогда проехали. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 07:58 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAТы включил дурака типа? Ну ладно, тогда проехали. У меня недоумение, почему у тебя практически всегда не к месту всплывают какие-то Ruby, PHP, Java? Это заболевание гика такое? Тебя загикали? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 08:48 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
blest, все зависит от потребностей: * минимальный набор - это сущность, без бизнес логики в этой сущности, делаешь маппинг на таблицы бд при помощи какой либо орм и эту же сущность же используешь во всех слоях - бизнес и презентационном дальше по нарастающей * у тебя могут появиться несколько интерфейсов для редактирования одной сущности, но с разным набором полей - делаешь несколько model и маппинг model в сущность, чтоб не загрязнять сущность * у тебя появляются проблемы с crud операциями, например веб - телерик кендо - entity framework: без моделей эта связка будет выносить тебе мозг - сделаешь model и маппинг на сущность - все встанет на свои места * ты можешь сделать полноценные доменные сущности с бизнес логикой и уже не сможешь легко и просто замапить их на таблицы бд - делаешь отдельный набор моделей для orm и маппинга на таблицы, а доменные сущности маппишь в эти модели orm * у тебя появится сервис для внешних потребителей - ты не сможешь отдать им доменные сущности, только dto (= model), которые будут сериализовываться в xml/json * и так далее и тому подобное твои внутренние бизнес-службы с логикой могут работать как с сущностями так и с моделями, просто организуй понятным образом и еще почитай еще про cqrs - избавишься от мега-служб с кучей методов ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 09:46 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAТы включил дурака типа? Ну ладно, тогда проехали. У меня недоумение, почему у тебя практически всегда не к месту всплывают какие-то Ruby, PHP, Java? Это заболевание гика такое? Тебя загикали? А ты высуни голову из своего энтерпрайза и попытайся понять :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 10:38 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAА ты высуни голову из своего энтерпрайза и попытайся понять :) А чё там понимать, есть JSON и XML кому надо, и плевать как там внешний PPP называется. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 11:09 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAА ты высуни голову из своего энтерпрайза и попытайся понять :) А чё там понимать, есть JSON и XML кому надо, и плевать как там внешний PPP называется.Скорее так: плевать рынок и конкуренты хотели на икверибл. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 12:50 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAhVosttпропущено... А чё там понимать, есть JSON и XML кому надо, и плевать как там внешний PPP называется.Скорее так: плевать рынок и конкуренты хотели на икверибл. Хм.. ты используешь C# интерфейсы и классы? А как же PHP? Они понимают эти интерфейсы и классы? Или плевать на рынок, хотели средства платформы и языка? Бредятину какую-то несёшь, чесслово. Для обмена с внешим миром есть расово верные XML и JSON, независит ни от платформы, ни от языка. Или я чего-то в твоём послании явно не понимаю ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 19:32 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
hVosttskyANAпропущено... Скорее так: плевать рынок и конкуренты хотели на икверибл. Хм.. ты используешь C# интерфейсы и классы? А как же PHP? Они понимают эти интерфейсы и классы? Или плевать на рынок, хотели средства платформы и языка? Бредятину какую-то несёшь, чесслово. Для обмена с внешим миром есть расово верные XML и JSON, независит ни от платформы, ни от языка. Или я чего-то в твоём послании явно не понимаю Явно не понимаешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2015, 22:12 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAЯвно не понимаешь. Ок, д'Артаньян ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2015, 08:02 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
Кстати, Планше, где моё бургундское? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2015, 08:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAКстати, Планше, где моё бургундское? Есть только торт и крендельки ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2015, 11:23 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
О, на DotNext Дино Эспозито выступит с двумя докладами о важности доменной модели и проектировании на основе предметной области. Надо ему сказать будет, что нет ORM, значит нет Entity :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2015, 16:34 |
|
Архитектура приложения, надо ли дублировать сущности под каждый слой
|
|||
---|---|---|---|
#18+
skyANAО, на DotNext Дино Эспозито выступит с двумя докладами о важности доменной модели и проектировании на основе предметной области. Надо ему сказать будет, что нет ORM, значит нет Entity :) Не знал, что он работает в JetBrains... считаю, что по этой теме хватит уже евангелизмом заниматься, нужны конкретные практики. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.10.2015, 19:22 |
|
|
start [/forum/topic.php?all=1&fid=20&tid=1401094]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
25ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
219ms |
get tp. blocked users: |
1ms |
others: | 324ms |
total: | 608ms |
0 / 0 |