|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
skyANAzz118POCO объекты доменной модели лучше держать в отдельной сборке MyProject.BusinessObjects, MyProject.Entities, MyProject.DomainModel...И что это даст и в каких случаях? В соседнем топике коммьюнити нервно прореагировало на ссылку на Фаулера, но тут лучше также обратиться к нему. В "Арихетктуре Enterrprise приложений" он признает, что объекты доменной модели - это в общем случае "архитектурный косяк" реализации 3-layer N-tier приложения, так как они используются всеми слоями. Иными словами, у нас должен быть набор объектов, к которым должен иметь доступ любой слой приложения. С другой стороны, если мы используем O/R Mapper, то нам необходимо контролировать процесс инициализации объектов нашей доменной модели. Как вариант можно пойти следующим путем: MyDataAccess.dll Код: c# 1. 2. 3. 4. 5. 6. 7.
MyDomain.dll Код: c# 1.
MyDomainInterfaces.dll Код: c# 1.
MyBusinessLayer.dll Код: c# 1. 2. 3. 4. 5. 6.
Соответственно, зависимости между проектами: MyDataAccess.dll -> MyDomain.dll MyDataAccess.dll -> MyDomainInterfaces.dll MyDomain.dll -> MyDomainInterfaces.dll MyBusinessLayer.dll -> MyDomainInterfaces.dll MyBusinessLayer.dll -> MyDataAccess.dll Понятно что такой финт возможен только при явном отделении доменной модели. Также не следует забывать, что один слой доступа к данным может работать с несколькими доменами. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2016, 08:18 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
zz118, так я и не понял что нам, а точнее автору даст вынесение части доменной модели в отдельные сборки. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2016, 13:50 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
zz118Также не следует забывать, что один слой доступа к данным может работать с несколькими доменами. И что это значит? Что ТСу надо переделать референсы? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2016, 13:51 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
skyANAzz118, так я и не понял что нам, а точнее автору даст вынесение части доменной модели в отдельные сборки. Если я правильно понял, то автора скорее интересует набор подходов к решению таких задач. skyANAИ что это значит? Что ТСу надо переделать референсы? :) Я привел пример случая, когда размещение POCO объектов в отдельной сборке имеет преимущества. На сколько это имеет смысл для ТС, понятия не имею. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2016, 14:19 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
zz118skyANAzz118, так я и не понял что нам, а точнее автору даст вынесение части доменной модели в отдельные сборки. Если я правильно понял, то автора скорее интересует набор подходов к решению таких задач. Подходов множество, можно постоянно код переписывать. Выкинуть репозиторий, разложить всё по микросервисам, связать очередями :) Но пусть начнёт с простого, а потом его архитектура будет эволюционировать. zz118skyANAИ что это значит? Что ТСу надо переделать референсы? :) Я привел пример случая, когда размещение POCO объектов в отдельной сборке имеет преимущества. А можете на пальцах объяснить, в чём конкретно преимущества? А то я пока не понял. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2016, 14:28 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
Господа, вынесение моделей в отдельную сборку нет смысла обсуждать. Я не особо вижу смысла в этом, хотя это практикуется в примерах из гугла. У меня вопрос немного в другом. Насколько сборки должны быть самодостаточными? Ниже то, как это вижу я. Но я повторюсь, я учусь ... и не уверен что это правильно. Теория В собрке А есть класс1, который требует класс2. Сборка А должна содержать интерфейс, Сборки B, C и etc содержать класс2,3,4 etc которые будут иметь имплементацию от интерфейса в сборке А и смогут использоваться с классом1. Пример Cars.dll содержит Car, который требует Engine. Cars.dll содрежит IEngine. Engines.dll содержит Engine4V : IEngine (из Cars.dll), Engine6V : IEngine (из Cars.dll), Engine8V : IEngine (из Cars.dll) использование var volvo = new Car(new Engine4V) Теперь об Сервисах и Репозиториях. Как я понял все что имеет DbContextAppName хорошим тоном будет держать в одной сборке например DataAccess.EF Далее у нас сборка с логикой где есть класс UserService который требует UnitOfWork и UserRepository. Далее если следовать теории выше то логика должна иметь IUserRepository Сборки DataAccess.EF, DataAccess.MongoDb и etc содержат UserRepository : IUserRepository (из сборки логики) Далее получается следуя теории выше AppName.Mvc (UI) должен содержать IUserService. PS. Старался писать соблюдая логику. Все ли правильно? Хороших разжеванных примеров в гугле ненашел. Все как-то хаотично и/или опущенны детали. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 01:00 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
В примере с машинами видно что сборка Engines.dll содержит Engine4V : IEngine (из Cars.dll), то есть начинает зависеть от IEngine (из Cars.dll). То есть нарушается самодостаточность и правильнее наверное будет вот так. Cars.dll содержит Car, который требует Engine. Cars.dll содрежит IEngine. Engines.dll содержит Engine Volvo.dll Создем класс Engine4V : IEngine Метод GetNewCar return volvo = new Car(new Engine4V) Теперь нужно перенести это на Service и Repository Подумаю об этом завтра ... )) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 01:20 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
Артем GВ примере с машинами видно что сборка Engines.dll содержит Engine4V : IEngine (из Cars.dll), то есть начинает зависеть от IEngine (из Cars.dll). То есть нарушается самодостаточность и правильнее наверное будет вот так. Cars.dll содержит Car, который требует Engine. Cars.dll содрежит IEngine. Engines.dll содержит Engine Volvo.dll Создем класс Engine4V : IEngine Метод GetNewCar return volvo = new Car(new Engine4V) Теперь нужно перенести это на Service и Repository Подумаю об этом завтра ... ))Лучше думать о более практичных вещах, например: логика, расположенная в данной сборке, должна использоваться в Asp Net MVC, WPF и Console приложениях. После этого продумываются зависимости между сборками, после этого вопросов, где и как располагаются классы/интерфейсы, возникать не должно - скомпилировалось, значит всё правильно. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 05:31 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
skyANAНо пусть начнёт с простого, а потом его архитектура будет эволюционировать.+ ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 05:34 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
Алексей КskyANAНо пусть начнёт с простого, а потом его архитектура будет эволюционировать.+ На работе так и поступаю иначе все бы стояло и ни куда не двигалось. Эти вопросы решаю вне работы :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 07:15 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
Артем GДалее получается следуя теории выше AppName.Mvc (UI) должен содержать IUserService. А можете толком объяснить, зачем Вам интерфейс IUserService? ИМХО он не нужен. По остальному я уже ответил: "IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой". ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 08:24 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
skyANAА можете на пальцах объяснить, в чём конкретно преимущества? А то я пока не понял. 1. Зависимости. Понятно, что репозитории должны использовать объекты доменной модели как в роли переносчиков данных. В таком случае, доменная модель находится или в одной сборке с репозиториями, или в отдельной. С другой стороны, объекты доменной модели должны быть использованы в UI слое. В результате простой выбор: или UI имеет ссылку на DAL, или доменную модель нужно выделять отдельно. 2. Инкасуляция. Подробно я писал про это выше. Часто "удобно" показывать UI слою не всю доменную модель, а только ее часть (часть объектов скрывать совсем или возвращать как интерфейсы). Понятно что тогда нужно разбивать домен на несколько составных частей с соответствующими областями видимости. 3. Сегрегация источников данных. Разные объекты доменной модели могут находится в различных хранилищах и, соответственно, могут иметь разные слои доступ к данным. Соответетствующая сегрегация должна быть на сборках. Тут "прямое" разделение классов может "не влететь", так как через него не получится добиться полной работоспособности persistent cache на оба хранилища. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 10:16 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
Алексей Кскомпилировалось, значит всё правильно. К сожалению, приходилось работать с legacy кодом, который так писался. Не очень приятные воспоминания. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 10:18 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
zz118skyANAА можете на пальцах объяснить, в чём конкретно преимущества? А то я пока не понял. 1. Зависимости. Понятно, что репозитории должны использовать объекты доменной модели как в роли переносчиков данных. В таком случае, доменная модель находится или в одной сборке с репозиториями, или в отдельной в отдельной сборке. С другой стороны, объекты доменной модели должны быть использованы в UI слое. В результате простой выбор: или UI имеет ссылку на DAL, или доменную модель нужно выделять отдельно UI имеет ссылку на DAL и на доменную модель. 2. Инкасуляция. Подробно я писал про это выше. Часто "удобно" показывать UI слою не всю доменную модель, а только ее часть (часть объектов скрывать совсем или возвращать как интерфейсы). Понятно что тогда нужно разбивать домен на несколько составных частей с соответствующими областями видимости. 3. Сегрегация источников данных. Разные объекты доменной модели могут находится в различных хранилищах и, соответственно, могут иметь разные слои доступ к данным. Соответетствующая сегрегация должна быть на сборках. Тут "прямое" разделение классов может "не влететь", так как через него не получится добиться полной работоспособности persistent cache на оба хранилища. Хм, ну вообщем подход "IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой" всему этому удовлетворяет. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 12:09 |
|
Вопрос по архитектуре
|
|||
---|---|---|---|
#18+
zz118Алексей Кскомпилировалось, значит всё правильно. К сожалению, приходилось работать с legacy кодом, который так писался. Не очень приятные воспоминания.Уверен, что через пару лет ты не будешь так же относиться к своему сегодняшнему коду? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2016, 14:14 |
|
|
start [/forum/topic.php?fid=20&msg=39212256&tid=1400673]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 282ms |
total: | 410ms |
0 / 0 |