tag:blogger.com,1999:blog-8864435396524375431.post5019734577216984188..comments2009-08-12T19:31:37.550+03:00Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-8864435396524375431.post-62258151563892406472009-08-12T19:31:37.550+03:002009-08-12T19:31:37.550+03:00Угу, текущий проект и использует эту архитектуру. Ессно что иземенненное. Но суть именно такая.Mike Chaliyhttp://chaliy.name/noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-45568120262676159532009-08-12T18:31:13.468+03:002009-08-12T18:31:13.468+03:00Перечитал статьи по onion. Ок, теперь я понял смысл и разобрался в том, что мне не очень нравилось. Автор говорит о физических зависоимостях, а не о логических.<br /><br /><i>Key tenets of Onion Architecture:<br /><br /> * The application is built around an independent object model<br /> * Inner layers define interfaces. Outer layers implement interfaces<br /> * Direction of coupling is toward the center<br /> * All application core code can be compiled and run separate from infrastructure</i><br /><br />Ну, и стрелочек наружу в его диаграммах тоже нет, это сбивало с толку.<br /><br />Уже пробовали реализовать такую архитектуру в реальности?Александр Кондуфоровhttp://www.blogger.com/profile/03000892844767433158noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-47095728141491228482009-08-12T18:06:18.118+03:002009-08-12T18:06:18.118+03:00Игорь: Что такое инфраструктура сохранения - не знаю, я вроде бы такое не писал... Слой сохранения можно понимать как обычный DAL. В терминах DDD он же является инфраструктурой. В принципе, Миша внизу правильно расписал: реализацию репозитория можно отнести в эту самую инфраструктуру, контракты - выше, в BL/ядре. А вот места вызовов Add()/Get() у репозитория - это как раз то, о чем я спрашиваю.<br /><br />Когда BL использует DAL (обычная многослойная архитектура) - все понятно. Классы BL (те же Мишины MembershipService, ProductPublisher, StoreManager) вызывают через контракты заинжекченных репозиториев методы Add/Get у конкретных реализаций. Но как в случае с Onion? Согласно приведенной диаграмме и вашему описанию <i>&quot;Другие модули выстраиваются вокруг ядра таким образом, чтобы их зависимости были направлены вовнутрь к ядру&quot;</i> и <i>&quot;Зависимости в противоположную торону от ядра недопустимы&quot;</i>. Вот я и пытаюсь понять, каким образом мои репозитории вдруг будут зависеть от моего ядра? Скорее всего, подразумевается то, что написал Миша: <i>&quot;Далее есть слой приложения (IMembershipService, IProductPublisher, IStoreManager). В него инжектяться репозитраии&quot;</i>. Но тогда диаграмма с Database и UI явно либо неверна, либо символична, потому что объективно UI (хотя бы в виде его контроллера) имеет зависимость на ядро, а вот Database, изображенный аналогично - нет.<br /><br />Миш, спасибо за описание. В принципе, я тоже это все именно так и понимаю, но тогда где-то в диаграмме и ее описание есть ошибка... Или, возможно, я просто чего-то недопонял :)Александр Кондуфоровhttp://www.blogger.com/profile/03000892844767433158noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-22363374694792207542009-08-12T16:41:03.248+03:002009-08-12T16:41:03.248+03:00Убрать слой сохранения. И все упрощаеться. <br /><br />Смотри по Игоря схеме есть модель(Domain Logic - шо за фигня?). В нее же входят и репозитраии. Точнее контракты репозитариев.<br /><br />Далее есть инфраструктура в ней есть реалзиации этих репозитариев.<br /><br />Далее есть слой приложения (IMembershipService, IProductPublisher, IStoreManager). В него инжектяться репозитраии.<br /><br />Тоесть фактически получаеться что нема слоев. Есть один большой модуль бизнеслогики (и небольшой хак ввиде заинжекченых реальных репозитареив да внешних сервисов).<br /><br />Как то плутано получилось ;(. Это проще кодом расказать.Mike Chaliyhttp://chaliy.name/noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-61939696999227621792009-08-12T16:26:44.980+03:002009-08-12T16:26:44.980+03:00Что такое инфраструктура сохранения? Вызов методов Add(...)/Get(...) у репозитория - это BL или инфраструктура в заданном вопросе?Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-22760213259979113712009-08-12T13:17:05.212+03:002009-08-12T13:17:05.212+03:00Миш, поправка принимается. В некотгорых местах, де я писал про модель, я понимал слойбизнес логики в целом. Надо быть точнее с терминами, но судя по твоему ответу мы поняли друг друга :)<br /><br />Согласно твоим словам, команду прочитать/сохранить данные отдает какой-то код отдельного слоя или контроллера MVC. По сути, это почти то же самое, что я писал, хотя и напутал, где модель, где BL/ядро :)<br /><br /><i>&quot;Логика подсказывает что здесь тоже может быть какой-нибудь &quot;контроллер&quot;, который позволит отделить данные от модели, так чтобы они ничего не знали друг о друге. Или, возможно, нужно реализовать какую-нибудь &quot;логику приложения&quot;, которая будет связывать модель с инфраструктурой. Кстати, здесь очень часто используются все те же контроллеры UI (MVC), но не уверен, что это правильно.&quot;</i><br /><br />С контроллерами MVC все понятно, за исключением того, почему они вдруг что-то знают про сохранение модели. По идее, это не их дело, что там BL (ядро) делает с целью сохранения своего состояния. Мне кажется, что инфраструктурные вопросы ядра должно решать само ядро, которое должно быть сконфигурировано для этого соответствующим образом. Так вот интересно, как правильно реализовать вот это взаимодействие между BL/ядром и слоем сохранения. В терминах Onion, Hexagonal, DDD или чего угодно еще :) Спасибо!Александр Кондуфоровhttp://www.blogger.com/profile/03000892844767433158noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-6954839175376315392009-08-12T12:58:54.337+03:002009-08-12T12:58:54.337+03:00Саша, привет.<br /><br />Модель это набор сущностей, это не набор оперций над сущностями. Поэтому не может модель управлять сохранением/чтением. <br /><br />Модель позволяет коду твоего приложения моделировать ситуации. Так например есть продукт и есть склад. Код приложения должен взять обьекты модели(тока приложение знает где их взять) и добавить продукт в склад. И после этого их сохранить.<br /><br /><br />В зависимости от потребностей код приложения может быть в отдельном слое(слой приложения) или в простых случая контроллер МВЦ.<br /><br />По идее так.Mike Chaliyhttp://chaliy.name/noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-58959378464431310072009-08-12T12:09:57.350+03:002009-08-12T12:09:57.350+03:00Игорь, спасибо за пост. Есть пара мыслей по этому поводу.<br /><br />Мне тоже нравится идея первоочередности доменной модели, а не базы данных. База данных, файловая система, внешние источники данных - это всего лишь слой сохранения, по сути, инфраструктура. И эта инфраструктура нужна нам лишь для того, чтобы где-то сохранять состояние нашей модели между запусками приложения или с целью обеспечения восстановления данных после возможного сбоя, а также оптимизировать использование памяти. В идеальной среде наше приложение могло бы вечно крутиться в памяти и держать свое состояние в памяти, но среда не идеальна...<br /><br />Так вот, к чему это я. UI зависит от состояния модели и вляет на него - это понятно. Сюда можно положить MVC или что-то другое. Контроллеры знают, что есть модель, UI не знает - все замечательно. Но как насчет инфраструктуры? Управляет ли модель своим сохранением или нет? Согласно Onion architecture - нет, потому что зависимости направлены внутрь ядра. В то же время очень часто ситуация обратная - как раз модель знает, что нужно пойти и сохранить свое состояние куда-нибудь, или пойти и получить его, материализовав объекты в памяти.<br /><br />Логика подсказывает что здесь тоже может быть какой-нибудь &quot;контроллер&quot;, который позволит отделить данные от модели, так чтобы они ничего не знали друг о друге. Или, возможно, нужно реализовать какую-нибудь &quot;логику приложения&quot;, которая будет связывать модель с инфраструктурой. Кстати, здесь очень часто используются все те же контроллеры UI, но не уверен, что это правильно. Так все же как это лучше реализовать?Александр Кондуфоровhttp://www.blogger.com/profile/03000892844767433158noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-7959188981894267182009-07-18T09:15:19.098+03:002009-07-18T09:15:19.098+03:00Можно. Но так было бы скучно резюмировать каждый второй пост :)Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-47412180690212472452009-07-18T09:06:45.172+03:002009-07-18T09:06:45.172+03:00все эти мысли можно было резюмировать в low coupling, high cohesion, не? :-)Igor Katkovhttp://www.katkovonline.com/noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-32634095376217245612009-07-17T08:30:16.200+03:002009-07-17T08:30:16.200+03:00DataMapper как бы ортогонален к рассматриваемой проблеме. Например, на втором рисунке он <i>может</i> использоваться (а может и нет) в классах SqlServerRepository. Точно так же в классах WebFormsController паттерн DataMapper может использоваться для преобразования данных из формата модели домена в формат, удобный для отображения.<br /><br />DataMapper - это всего лишь утилитка, которая знает, как данные в двух форматах соответствуют друг другу. Не более того. Не нужно его переоценивать.<br /> <br />Но. Использование этого паттерна, условно говоря, там не обязательно. И его наличие либо отсутствие сути описанной проблемы не меняет.Igorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-74473638300028214312009-07-16T01:06:35.417+03:002009-07-16T01:06:35.417+03:00Спасибо, интересно.<br /><br />Вообще говоря не согласен с постанвкой вопроса<br /><i><br />Все бы хорошо, но данная схема подразумевает первичность базы данных. Ее разработка влияет на все остальные уровни. И в случае, если мы хотим смоделировать бизнес-логику, используя Domain Driven Design, это влияние будет столь значительным, что рано или поздно все попытки разработать полноценную модель скатятся в использование Active Record или Table Module, похоронив все дальнейшие попытки использования преимуществ возможностей богатой модели. </i><br /><br />Как насчёт Data Mapper?RedMacGhttp://www.blogger.com/profile/01207522829685056098noreply@blogger.com