ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Вопрос по архитектуре
40 сообщений из 40, показаны все 2 страниц
  все  
Вопрос по архитектуре
    #39211539
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
Есть 2 библиотеки,
в первой библиотеке есть класс в конструкторе которого есть интерфейс. Вторая библиотека добавлена в референс в первой библиотеки.
во второй библиотеке этот интерфейс и плюс класс к которому имплементирован этот интерфейс.

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

PS
Вот на примере из жизни.
1я библиотека бизнес логика имеет класс UserService, который содержит в конструкторе IUserRepository.
2я библиотека слой данных и имеет класс UserRepository, который имплементирован от IUserRepository.

Думаю перетащить IUserRepository в 1ю библиотеку, чтобы если придеться заменять 2ю библиотку, то 1я не должна будет "сыпаться".
Так же думаю IUserService перетащить в клиент из логики.

Что скажите? спрашиваю потому как чую, что сейчас не правильно, но не уверен что так правильно потому как в гугл-примерах, так как сейчас у меня.
...
Рейтинг: 0 / 0
09.04.2016, 00:19
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211543
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
Попробывал перетащить итерфес и пришел к выводу что вероятно они должны быть вообще в отдельной сборке.
...
Рейтинг: 0 / 0
09.04.2016, 00:47
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211546
Фотография Antonariy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Antonariy
Участник
Артем GЧто скажите? лучше код покажи, а то фраза "в конструкторе которого есть интерфейс" уже за гранью добра и зла.

конструктор это Sub New, как в нем может быть описан интерфейс - загадка.
...
Рейтинг: 0 / 0
09.04.2016, 01:06
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211547
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
AntonariyАртем GЧто скажите? лучше код покажи, а то фраза "в конструкторе которого есть интерфейс" уже за гранью добра и зла.

конструктор это Sub New, как в нем может быть описан интерфейс - загадка.
кусок кода для примера
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
     public class UserService : IUserService
    {
        private readonly IUserRepository userRepository;

        public UserService(IUserRepository userRepository)
        {
            this.userRepository = userRepository;
        }



почитал вот тут линк
пишут что создаются persistence layers между слоем данных и логикой и между логикой и интерфейсом
...
Рейтинг: 0 / 0
09.04.2016, 01:11
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211560
Фотография Antonariy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Antonariy
Участник
Артем Gкусок кода для примерагде тут одна библиотека, где вторая? где описание интерфейса и вообще всего того, о чем идет речь в первом посте?
...
Рейтинг: 0 / 0
09.04.2016, 02:26
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211562
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
ох, думал на словах будет проще для все ... ситуция то "будничная"
ок, раз на словах ни как, тогда выложу код днем. сейчас 4ый час ночи...
спасибо за желание помочь.
...
Рейтинг: 0 / 0
09.04.2016, 03:23
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211575
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
Все зависит то того, что хочется получить в результате. Поясню на двух примерах:

1. В зависимости от фазы луны мы хотим работать или с файловой системой, или с БД. Тогда выделяем классы, специфичные для типа хранилища в отдельную сборку, а их интерфейс вообще отдельно.

FileSystemRepository.dll
Код: c#
1.
internal class FileSystemRepository : IRepository {}



DatabaseRepository.dll
Код: c#
1.
internal class DatabaseRepository: IRepository {}



Contracts.dll
Код: c#
1.
public interface IRepository {}



SomeUsage.dll
Код: c#
1.
2.
3.
4.
internal class DepenencyConsumer 
{
    public DepenencyConsumer(IRepository repository)
}



Соответственно зависимости:
SomeUsage.dll -> Contracts.dll
DatabaseRepository.dll -> Contracts.dll
FileSystemRepository.dll -> Contracts.dll

2. Мы пишем библиотеку FileSystemRepository.dll, которую поставляем как часть SDK. Тогда мы хотим сделать код закрытым для модификаций, тогда все по другому

FileSystemRepository.dll
Код: c#
1.
2.
3.
internal class FileSystemRepository : IRepository {}

public interface IRepository {}



SomeUsage.dll
Код: c#
1.
2.
3.
4.
internal class DepenencyConsumer 
{
    public DepenencyConsumer(IRepository repository)
}



Зависимости:
SomeUsage.dll -> FileSystemRepository.dll

Я оставил за скобкой как именно инъектируются зависимости, но думаю с этим не должно возникнуть проблем.
...
Рейтинг: 0 / 0
09.04.2016, 08:17
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211579
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Артем G, IUserService, IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой.
И кстати интерфейс IUserService наверняка на фиг не нужен.
...
Рейтинг: 0 / 0
09.04.2016, 08:37
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211582
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
skyANAАртем G, IUserService, IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой.
И кстати интерфейс IUserService наверняка на фиг не нужен.

Не получится тогда что реализация IUserRepository ссылается на собственного потребителя?
...
Рейтинг: 0 / 0
09.04.2016, 08:47
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211641
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118skyANAАртем G, IUserService, IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой.
И кстати интерфейс IUserService наверняка на фиг не нужен.

Не получится тогда что реализация IUserRepository ссылается на собственного потребителя?
Бррр... Ну и формулировочка :)

Очевидно, что мы добавим референс на сборку, где реализуется нужный нам интерфейс. Или подключим её иным способом. Но что тут может вызывать не понимания?
...
Рейтинг: 0 / 0
09.04.2016, 13:00
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211642
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Хотя может я Вас не верно понял..

Потребитель реализации IUserRepository - это UserService. При этом ссылки реализации на потребителя нет. Где Вы её усмотрели?
...
Рейтинг: 0 / 0
09.04.2016, 13:02
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211656
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Продемонстрирую картинкой..
...
Рейтинг: 0 / 0
09.04.2016, 14:36
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211667
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
skyANAПри этом ссылки реализации на потребителя нет. Где Вы её усмотрели?
В примере на картинке Data ссылается на DomainModel, в которой расположен потребитель репозитория. Такая реализация плохо масштабируема, так как при увеличении числа потребителей и/или интерфейсов (например, при применении I. из S.O.L.I.D.) сборка Data становится "жадной".
...
Рейтинг: 0 / 0
09.04.2016, 15:33
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211669
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118, конкретный пример привести можете?

Речь ведь не об абстрактном репозитории, а о конкретном I User Repository, что должен возвращать не что иное как User -ов.
...
Рейтинг: 0 / 0
09.04.2016, 15:53
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211674
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
Попробую:

Шаг 1. Обычный CRUD
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
// ---------- Repository.dll -------------
internal class UserRepository : IUserRepository
{
    IEnumerable<User> Get() {...}

    void Set (IList<User> users) {...}
}
....
// ---------- MyDomain.dll -------------
public interface IUserRepository
{
    IEnumerable<User> Get();

    void Set (IList<User> users);
}



Шаг 2. Прикручиваем отчетный движок к пользователям
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
// ---------- Repository.dll -------------
public class UserRepository : IUserProducer, IUserRepository
{
    IEnumerable<User> Get() {...}

    void Set (IList<User> users) {...}
}

....
// ---------- MyDomain.dll -------------
public interface IUserRepository
{
    IEnumerable<User> Get();

    void Set (IList<User> users);
}
// ---------- MyReportingDomain.dll -------------
public interface IUserProducer
{
    IEnumerable<User> Get();
}



Шаг 3. Прикручиваем приложение для win-mobile с ограниченным функционалом
Код: 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.
// ---------- Repository.dll -------------
public class UserRepository : IUserProducer, IUserRepository, ISimpleUserProvider
{
    IEnumerable<User> Get() {...}

    void Set (IList<User> users) {...}

    IEnumerable<UserDto> SimpleGet() {...}
}

....
// ---------- MyDomain.dll -------------
public interface IUserRepository
{
    IEnumerable<User> Get();

    void Set (IList<User> users);
}
// ---------- MyReportingDomain.dll -------------
public interface IUserProducer
{
    IEnumerable<User> Get();
}
// ---------- MyMobileDomain.dll -------------
public interface ISimpleUserProvider
{
    IEnumerable<UserDto> SimpleGet() {...}
}



Все бы ничего, но проблема находится вот в этой строке:
Код: c#
1.
public class UserRepository : IUserProducer, IUserRepository, ISimpleUserProvider


Из-за нее мы в каждый из трех доменов тянем лишние сборки которые там могут быть в принципе не релевантны. Вдобавок, UserRepository начинает обладать знаниями о том кто и как его использует. Как следствие, мы не сможем разрабатывать его отдельно.
...
Рейтинг: 0 / 0
09.04.2016, 16:32
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211677
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118, амн... А при чём тут моё предложение: "IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой"?

Реализаций IUserRepository может быть несколько, каждая в своей сборке. И каждая из них будет зависеть только от того, что ей действительно нужно.

И соответсвенно в конкретном приложении будет подключена конкретная сборка.
...
Рейтинг: 0 / 0
09.04.2016, 16:50
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211695
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
skyANAzz118, амн... А при чём тут моё предложение: "IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой"?

Реализаций IUserRepository может быть несколько, каждая в своей сборке. И каждая из них будет зависеть только от того, что ей действительно нужно.

И соответсвенно в конкретном приложении будет подключена конкретная сборка.
1. Создал проект на GitHub Для того, чтобы можно было глянуть в живую что и как
2. На картинке видно что IUserRepository в сборке DataAccess. Там где реализация, то есть вместе с UserRepository.
Видно что сборка BusinessLogic использует IUserRepository в конструкторе.

Я все еще в процессе обучения и поэтому не знаю как правильно. Этот вариант был взят из интернета.
Я засомневалася что IUserRepository толжен быть с сборке DataAccess.

Теперь вопросы.
1. Оставить IUserRepository в DataAccess? - это правильно?
2. Перенсти в BusinessLogic. Как тогда имплементировать IUserRepository для UserRepository?
3. Создать отдельную сборку (видел вариант с названием Persistent) которая добавляется и в BusinessLayer и в DataAccess.

4. Если переносим IUserRepository из DataAccess что делать с моделями. На картинке видно что DataAccess имеет модель User
а IUserRepository содержит функцию User GetUser(int Id);

Вобщем вопросов куча (( не понять толком как правильно ...

...
Рейтинг: 0 / 0
09.04.2016, 18:35
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211697
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
автор1. Оставить IUserRepository в DataAccess? - это правильно?

да

автор4. Если переносим IUserRepository из DataAccess что делать с моделями. На картинке видно что DataAccess имеет модель User
а IUserRepository содержит функцию User GetUser(int Id);

POCO объекты доменной модели лучше держать в отдельной сборке MyProject.BusinessObjects, MyProject.Entities, MyProject.DomainModel...
...
Рейтинг: 0 / 0
09.04.2016, 18:49
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211707
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
zz118автор1. Оставить IUserRepository в DataAccess? - это правильно?
да
автор4. Если переносим IUserRepository из DataAccess что делать с моделями. На картинке видно что DataAccess имеет модель User
а IUserRepository содержит функцию User GetUser(int Id);
POCO объекты доменной модели лучше держать в отдельной сборке MyProject.BusinessObjects, MyProject.Entities, MyProject.DomainModel...
Ок понял. Сделаю именно так.
Но все же переспрошу. Студенческий вопрос :). То есть это нормально, что в сборке BusinessLogic требуется IUserRepository, но сборка не предоставляет возможности использовать саму сборку без сборки DataAccess в которой IUserRepository находится?

PS/ в дополнение...
Сейчас понимаю, что если я перенсу IUserRepository в BusinessLogic то придется или подключать Domain в котором будет модель User, дополнительно не понять как имплементировать IUserRepository во время реализации UserRepository (наверное ни как :) ).


Спасибо за ответы.
...
Рейтинг: 0 / 0
09.04.2016, 19:13
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211716
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Артем G1. Оставить IUserRepository в DataAccess? - это правильно?
2. Перенсти в BusinessLogic. Как тогда имплементировать IUserRepository для UserRepository?
3. Создать отдельную сборку (видел вариант с названием Persistent) которая добавляется и в BusinessLayer и в DataAccess.
Не место IUserRepository в одной сборке с конкретным UserRepository.
Можете конечно оставить там, тогда реализацию надо вынести в сборку: DataAccess.SqlClient, или DataAccess.NHibernate, или DataAccess.EntityFramework, или DataAccess.MongoDB, - в зависимости от начинки этой самой реализации.
...
Рейтинг: 0 / 0
09.04.2016, 19:39
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211720
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Артем G, вот зачем в BusinessLogic ссылка на DataAccess?

В том проекте, где используете логику (консолька, сервис, сайт, формы), там и добавляйте ссылку на ту реализацию доступа к данным, что нужна.
...
Рейтинг: 0 / 0
09.04.2016, 19:50
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211724
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118POCO объекты доменной модели лучше держать в отдельной сборке MyProject.BusinessObjects, MyProject.Entities, MyProject.DomainModel...И что это даст и в каких случаях?
...
Рейтинг: 0 / 0
09.04.2016, 19:52
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211732
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
skyANAАртем G, вот зачем в BusinessLogic ссылка на DataAccess?
В том проекте, где используете логику (консолька, сервис, сайт, формы), там и добавляйте ссылку на ту реализацию доступа к данным, что нужна.
На скрине что выше видно, что сейчас IUserRepository в DataAccess, и в BusinessLogic в конструкторе UserService. Поэтому ссылка.
На скрине что ниже видно что в консоле ссылка на BusinessLogic и в консоле используется UserService.

skyANAАртем G1. Оставить IUserRepository в DataAccess? - это правильно?
2. Перенсти в BusinessLogic. Как тогда имплементировать IUserRepository для UserRepository?
3. Создать отдельную сборку (видел вариант с названием Persistent) которая добавляется и в BusinessLayer и в DataAccess.
Не место IUserRepository в одной сборке с конкретным UserRepository.
Можете конечно оставить там, тогда реализацию надо вынести в сборку: DataAccess.SqlClient, или DataAccess.NHibernate, или DataAccess.EntityFramework, или DataAccess.MongoDB, - в зависимости от начинки этой самой реализации.
Идея с DataAccess.EntityFramework очень даже симпотична. Выглядит логично. Cпасибо.

...
Рейтинг: 0 / 0
09.04.2016, 20:31
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211786
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
Артем Gzz118пропущено...
да
пропущено...
POCO объекты доменной модели лучше держать в отдельной сборке MyProject.BusinessObjects, MyProject.Entities, MyProject.DomainModel...
Ок понял. Сделаю именно так.
Но все же переспрошу. Студенческий вопрос :). То есть это нормально, что в сборке BusinessLogic требуется IUserRepository, но сборка не предоставляет возможности использовать саму сборку без сборки DataAccess в которой IUserRepository находится?
PS/ в дополнение...
Сейчас понимаю, что если я перенсу IUserRepository в BusinessLogic то придется или подключать Domain в котором будет модель User, дополнительно не понять как имплементировать IUserRepository во время реализации UserRepository (наверное ни как :) ).
Спасибо за ответы.
Если есть у кого-нибудь ответ на вопрос, то интересно было бы услышать.
...
Рейтинг: 0 / 0
09.04.2016, 23:38
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211847
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
Артем GЕсли есть у кого-нибудь ответ на вопрос, то интересно было бы услышать.

Я постарался описать сценарий, когда это не нормально (когда нужно "на лету" переключать зависимости). Не похоже что это Ваш случай, так что не вижу никаких рисков в такой зависимости.
...
Рейтинг: 0 / 0
10.04.2016, 08:04
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211849
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
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.
....
public IMyEntity Get()
{
    MyEntity x = EntityFramework.FetchMyEntity();
    return x;
}
...



MyDomain.dll
Код: c#
1.
public class MyEntity : IMyEntity { ... }



MyDomainInterfaces.dll
Код: c#
1.
public interface IMyEntity { ... }



MyBusinessLayer.dll
Код: c#
1.
2.
3.
4.
5.
6.
...
{
   var repository = provider.GetSomething();
   IMyEntity x = repository.Get();
}
...



Соответственно, зависимости между проектами:

MyDataAccess.dll -> MyDomain.dll
MyDataAccess.dll -> MyDomainInterfaces.dll
MyDomain.dll -> MyDomainInterfaces.dll
MyBusinessLayer.dll -> MyDomainInterfaces.dll
MyBusinessLayer.dll -> MyDataAccess.dll

Понятно что такой финт возможен только при явном отделении доменной модели. Также не следует забывать, что один слой доступа к данным может работать с несколькими доменами.
...
Рейтинг: 0 / 0
10.04.2016, 08:18
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211900
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118, так я и не понял что нам, а точнее автору даст вынесение части доменной модели в отдельные сборки.
...
Рейтинг: 0 / 0
10.04.2016, 13:50
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211901
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118Также не следует забывать, что один слой доступа к данным может работать с несколькими доменами.
И что это значит? Что ТСу надо переделать референсы? :)
...
Рейтинг: 0 / 0
10.04.2016, 13:51
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211905
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
skyANAzz118, так я и не понял что нам, а точнее автору даст вынесение части доменной модели в отдельные сборки.

Если я правильно понял, то автора скорее интересует набор подходов к решению таких задач.

skyANAИ что это значит? Что ТСу надо переделать референсы? :)

Я привел пример случая, когда размещение POCO объектов в отдельной сборке имеет преимущества. На сколько это имеет смысл для ТС, понятия не имею.
...
Рейтинг: 0 / 0
10.04.2016, 14:19
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39211910
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118skyANAzz118, так я и не понял что нам, а точнее автору даст вынесение части доменной модели в отдельные сборки.

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

Но пусть начнёт с простого, а потом его архитектура будет эволюционировать.

zz118skyANAИ что это значит? Что ТСу надо переделать референсы? :)

Я привел пример случая, когда размещение POCO объектов в отдельной сборке имеет преимущества.
А можете на пальцах объяснить, в чём конкретно преимущества? А то я пока не понял.
...
Рейтинг: 0 / 0
10.04.2016, 14:28
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212086
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
Господа, вынесение моделей в отдельную сборку нет смысла обсуждать. Я не особо вижу смысла в этом, хотя это практикуется в примерах из гугла.

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

Теория

В собрке А есть класс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. Старался писать соблюдая логику. Все ли правильно?
Хороших разжеванных примеров в гугле ненашел. Все как-то хаотично и/или опущенны детали.
...
Рейтинг: 0 / 0
11.04.2016, 01:00
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212088
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем 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
Подумаю об этом завтра ... ))
...
Рейтинг: 0 / 0
11.04.2016, 01:20
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212102
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Артем 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 приложениях. После этого продумываются зависимости между сборками, после этого вопросов, где и как располагаются классы/интерфейсы, возникать не должно - скомпилировалось, значит всё правильно.
...
Рейтинг: 0 / 0
11.04.2016, 05:31
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212103
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
skyANAНо пусть начнёт с простого, а потом его архитектура будет эволюционировать.+
...
Рейтинг: 0 / 0
11.04.2016, 05:34
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212109
Артем G
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Артем G
Гость
Алексей КskyANAНо пусть начнёт с простого, а потом его архитектура будет эволюционировать.+
На работе так и поступаю иначе все бы стояло и ни куда не двигалось. Эти вопросы решаю вне работы :)
...
Рейтинг: 0 / 0
11.04.2016, 07:15
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212133
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Артем GДалее получается следуя теории выше AppName.Mvc (UI) должен содержать IUserService.
А можете толком объяснить, зачем Вам интерфейс IUserService? ИМХО он не нужен.

По остальному я уже ответил: "IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой".
...
Рейтинг: 0 / 0
11.04.2016, 08:24
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212256
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
skyANAА можете на пальцах объяснить, в чём конкретно преимущества? А то я пока не понял.

1. Зависимости. Понятно, что репозитории должны использовать объекты доменной модели как в роли переносчиков данных. В таком случае, доменная модель находится или в одной сборке с репозиториями, или в отдельной. С другой стороны, объекты доменной модели должны быть использованы в UI слое. В результате простой выбор: или UI имеет ссылку на DAL, или доменную модель нужно выделять отдельно.

2. Инкасуляция. Подробно я писал про это выше. Часто "удобно" показывать UI слою не всю доменную модель, а только ее часть (часть объектов скрывать совсем или возвращать как интерфейсы). Понятно что тогда нужно разбивать домен на несколько составных частей с соответствующими областями видимости.

3. Сегрегация источников данных. Разные объекты доменной модели могут находится в различных хранилищах и, соответственно, могут иметь разные слои доступ к данным. Соответетствующая сегрегация должна быть на сборках. Тут "прямое" разделение классов может "не влететь", так как через него не получится добиться полной работоспособности persistent cache на оба хранилища.
...
Рейтинг: 0 / 0
11.04.2016, 10:16
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212262
zz118
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zz118
Участник
Алексей Кскомпилировалось, значит всё правильно.

К сожалению, приходилось работать с legacy кодом, который так писался. Не очень приятные воспоминания.
...
Рейтинг: 0 / 0
11.04.2016, 10:18
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212413
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
zz118skyANAА можете на пальцах объяснить, в чём конкретно преимущества? А то я пока не понял.

1. Зависимости. Понятно, что репозитории должны использовать объекты доменной модели как в роли переносчиков данных. В таком случае, доменная модель находится или в одной сборке с репозиториями, или в отдельной в отдельной сборке. С другой стороны, объекты доменной модели должны быть использованы в UI слое. В результате простой выбор: или UI имеет ссылку на DAL, или доменную модель нужно выделять отдельно UI имеет ссылку на DAL и на доменную модель.

2. Инкасуляция. Подробно я писал про это выше. Часто "удобно" показывать UI слою не всю доменную модель, а только ее часть (часть объектов скрывать совсем или возвращать как интерфейсы). Понятно что тогда нужно разбивать домен на несколько составных частей с соответствующими областями видимости.

3. Сегрегация источников данных. Разные объекты доменной модели могут находится в различных хранилищах и, соответственно, могут иметь разные слои доступ к данным. Соответетствующая сегрегация должна быть на сборках. Тут "прямое" разделение классов может "не влететь", так как через него не получится добиться полной работоспособности persistent cache на оба хранилища.
Хм, ну вообщем подход "IUserRepository, UserService в одной сборке... Реализация IUserRepository в другой" всему этому удовлетворяет.
...
Рейтинг: 0 / 0
11.04.2016, 12:09
| Ответить | Цитировать | Написать  
Вопрос по архитектуре
    #39212547
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
zz118Алексей Кскомпилировалось, значит всё правильно.

К сожалению, приходилось работать с legacy кодом, который так писался. Не очень приятные воспоминания.Уверен, что через пару лет ты не будешь так же относиться к своему сегодняшнему коду?
...
Рейтинг: 0 / 0
11.04.2016, 14:14
| Ответить | Цитировать | Написать  
40 сообщений из 40, показаны все 2 страниц
  все  
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Вопрос по архитектуре
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=20&tid=1400673]:
 0ms
get settings:
 11ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 36ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 70ms
get tp. blocked users:
 2ms
others: 13ms
total:  169ms
созд. / загр.: 169ms
x
x
Закрыть


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