ASP.NET Core MVC - Создание коллекций объектов

@escoult · Регистрация: 09.01.2018

Author24 — интернет-сервис помощи студентам

Здравствуйте всем!
Я начинающий веб разработчик. Опыт минимальный, написал несколько простых магазинов. Пробую найти подходящий способ для создания объектов, содержащих в своих полях коллекции других объектов. Поясню суть проблемы. Для простоты, пусть это будет телефонная книга, и пусть это будут следующие объекты:

C#

class Person
{
    int Id
    string FirstName
    string LastName
 
    //nav
    virtual ICollection<Phone> Phones
}
 
class Phone
{
    int Id
    string PhoneNumber
 
    //nav
    int PersonId
    virtual Person Person 
}

Задача проста, создать объект Person с заданными пользователем именем, фамилией и несколькими номерами телефонов и внести новые объекты в базу данных. Думаю, будет удобным, если получение всех данных и сбор коллекции телефонов, будет происходить на одной странице. Полей с коллекциями, конечно же может быть куда больше, например фото, мейлы. Но для простоты я ограничился одним таким полем с телефонами.

В целом к решению такой задачи, у меня пока имеются три варианта.

1. Для каждого объекта создать свой контроллер. Использовать layout с tabs для каждой из коллекций главного объекта, генерировать ссылки, ведущие на нужный контроллер с параметром personId. А в методах котроллеров создавать соответствующие объекты с указанным personId и возвращать View c описанным layout. DRY соблюдается, каждый контроллер знает как работать со своим объектом. Но, имеет место хождение с контроллера на контроллер (многочисленные обращения к серверу). Плюс нужно всегда передавать personId, а значит он всегда должен где то быть и каждый метод каждого котроллера, должен его в это что то каждый раз помещать. Работает, но берут сомнения, рационален ли такой подход.

2. Использовать один контроллер - Persons. Поля коллекций добавлять через JS, для получения всех данных использовать одну страницу (можно с табами для удобства). Все данные получить в один метод Create и создать объект сразу с коллекциями. В этом случае нет обращения к другим котроллерам. Но сам котроллер Persons перегружен методами не относящимися к нему напрямую (содерджит CRUD других объектов). Также объект Phone может понадобиться в другом месте приложения. И тогда неизбежно наступит повтор кода.

3. Использовать предыдущий подход, но вынести методы CRUD (точнее их содержимое) для объектов коллекций в сервисы. Тогда контроллеры будут обращаться к сервисам своих объектов. Create - обращение к сервису, сохранение, возврат View. Тут нет повтора кода, но меня берут сомнения, правильно ли это.

Как вообще на практике реализутся подобные задачи? Может примерчик какой то простой. Самостоятельно ответа нигде не нашел (или не знаю как найти) где бы код посмотреть или почитать о способах реализации.

Спасибо.

@cunamy · 10.01.2018, 06:55

Вынеси логику из контроллера и используй репозиторий и паттерн UnitOfWork.
https://metanit.com/sharp/mvc5/23.3.php

Контроллера одного достаточно.

@Cupko · 10.01.2018, 17:25

escoult, мыслите от модели:
Созданием, удалением и редактированием модели Person, в том числе добавление телефонов для пользователя - для PersonController.
Созданием, удалением и редактированием модели Phone, в том числе добавление пользователья для телефона - для PhoneController.
Разница между добавление телефонов для пользователя и добавление пользователья для телефона в том, какую модель вы редактируете.

@escoult · 11.01.2018, 00:14 **[ТС]**

cunami
UnitsOfWork я не использую. Использую репозиторий с Generic Methods. Собственно, в этом случае, необходимость в UnitsOfWork отпадает.

В данном, простом приложении вполне можно обойтись одним контроллером. Тут модель Phone мне точно больше нигде не потребуется. Но если это скажем большой магазин. Телефоны могут быть у клиентов, у поставщиков, у пользователей, еще у кого либо.

Добавлено через 11 минут
Cupko
То же думал над этим. Но не додумал до конца. Как быть с вьюшками? Моделей две, какую вьюшку будет возвращать каждый контроллер? По идее, каждый свою. Но страница редактирования у меня одна. По крайней мере, для пользователя это должно выглядеть так. Открыл он какой то Person Details, хочет отредактирорвать. Но я не знаю, что он захочет редактировать. Может персональные данные, а может телефоны. Какую форму ему подсовывать? На странице, сколько бы у меня их не было, Submit все равно один. Как тогда должна выглядеть эта вьюшка, чтобы все поля модели были доступны для редактирования? Или все же по ссылкам его отправлять на контроллер той модели, которая редактируется?

@sau · 11.01.2018, 13:11

Сообщение от cunamy

паттерн UnitOfWork.

- это не паттерн , а антипаттерн от какого то индуса , один фигню написал , другие не думая подхватили.

Но страница редактирования у меня одна

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

@_exp10der_ · 11.01.2018, 14:03

Сообщение от sau

- это не паттерн , а антипаттерн от какого то индуса , один фигню написал , другие не думая подхватили.

Да ну быть не может. Microsoft так например не считает, со своей реализацией UnitOfWork в виде DbContext https://github.com/aspnet/Enti... ext.cs#L27

@Usaga · 11.01.2018, 14:47

Сообщение от sau

это не паттерн , а антипаттерн от какого то индуса

Зря вы так.

@sau · 11.01.2018, 20:14

Сообщение от _exp10der_

Да ну быть не может. Microsoft так например не считает, со своей реализацией UnitOfWork в виде DbContext

Ну ладно , тут вероятно можно по разному понимать реализацию паттерна , у мелкософта я не увидел криминала , а вот вариант по ссылке на метанит мне совершенно не понравился.
Если следовать определению:

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

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

И кстати , кто сказал что в майкрософт индусы не работают ? ) , приведенный пример реализации на метаните уж очень узконаправленный , сразу несколько сущностей тесно связываются общим Db контекстом ,в итоге теряем гибкость и возможность изменить для этой группы тип репозитория (скажем не SQL и не EF) , в то время как паттерн репозитория с этой целью и реализуется. Его конечно можно допилить , реализуя абстрактный контекст и т.п , но это все проще решается.

@cunamy · 11.01.2018, 21:23

Сообщение от sau

Ну ладно , тут вероятно можно по разному понимать реализацию паттерна , у мелкософта я не увидел криминала , а вот вариант по ссылке на метанит мне совершенно не понравился.

под статьей метаинт указывает ссылку откуда он взял реализацию паттерна https://docs.microsoft.com/en-... pplication

Добавлено через 47 минут
Я у себя раньше использовал вот такую релизацию от Julia Lerman, очень удобно тестить

C#

    public class UnitOfWork<TContext> : IUnitOfWork where TContext:IContext, new()
    {
        private readonly IContext _context;
 
 
        public UnitOfWork()
            :this(new TContext())
        {
        }
 
        public UnitOfWork(IContext context)
        {
            _context = context;
        }
        public int Save()
        {
            return _context.SaveChanges();
        }
 
        public IContext Context
        {
            get { return _context; }
        }
 
        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }
 
        protected virtual void Dispose(bool disposing)
        {
            if (disposing)
                if (_context != null)
                    _context.Dispose();
        }
    }

@m0nax · 12.01.2018, 22:31

А я использую https://github.com/mehdime/DbContextScope
Тихо мирно у себя в углу считаю это "серебряной пулей" в плане доступа к данным, у автора гигантская статья в которой описаны все возможные варианты их плюсы и минусы (я сам половину из них использовал и согласен)
он учел все "наивные" реализации IRepository и IUnitOfWork которым забит интернет и несколько прочих вещей и вариантов (да и я тоже)

бесконечно гибкая вещь, хоть 2-3 контекста, хоть репозитории(идеально вливаются), хоть напрямую используй контекст в кастомных сервисах

так же годится как для для специальных мест где критична производительность, так и для специальных мест где критична транзакционность - ногу отстрелить не дает (поначалу бесит правда, но ведь он прав(!!) 2 save быть не должно никогда)

а ну и да я уже 3 раза использовал либу в боевых проектах, 2 кровавый энтерпрайз 1 домашний, либа и ее идеология выдержала всё без каких-либо серьезных проблем, хоть веб, хоть обычные окна

@sau · 13.01.2018, 15:58

Сообщение от m0nax

А я использую https://github.com/mehdime/DbContextScope

ну и опять же , решаются узкие вопросы касательно EF и связанного с ним контекста , тем самым нарушая идеологию шаблона репозиториев. Они на то и абстрагированы интерфейсом , что реализация может быть для каждой сущности своя (БД , файл , облако) , и никакая узконаправленная специфика в виде контекста на этом уровне присутствовать не должна.
Тут , при необходимости , должен использоваться механизм распределенной транзакции , реализация которого уже зависит от обстоятельств.

А вот внтури уже конкретной реализации репозитория - который совсем не обязательно может быть элементарным , уже можно применять всякие контекстно зависимые штуки вроде DbContextScope или UnitOfWork, там они правомерны т.к решают задачу в своем контексте.

@Usaga · 13.01.2018, 16:02

sau, как-то я с вами не согласен. Идея "контекста" ни как не диктует способ хранения данных.

@sau · 13.01.2018, 16:15

Идея "контекста" ни как не диктует способ хранения данных.

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

C#

public class DataService
{
   IRepsitory<Entity1> rp1 //облако
   IRepsitory<Entity2> rp2 //файл
   IRepsitory<Entity3> rp3 //БД
 
   public void InsertMethod(ComplexModel Model)  
   {
         BeginTransaction()//открываем распределенную транзакцию
         rp1.Insert(Model.Data1);
         rp2.Insert(Model.Data2);
         rp3.Insert(Model.Data3);
         CommitTransaction();
   }
 
}

@Usaga · 13.01.2018, 16:21

sau, ну, "контекст" выступает в роли контейнера репозиториев. Совершенно не обязательно, что он (контекст) должен быть в одном лице. То, что он не везде нужен - спору нет. Это очередная абстракция для более-менее сложных проектов.

Но сама идея контекста не диктует правила хранения данных

@sau · 13.01.2018, 17:10

Сообщение от Usaga

sau, ну, "контекст" выступает в роли контейнера репозиториев.

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

Сообщение от sau

"контекст" выступает в роли контейнера репозиториев.

Все же я немного не понял этот момент. , скорее наоборот , контекст присутствует как частный случай в одной из конкретной реализации интерфейса репозитория , для его внутренних нужд , или мы о каком контексте ведем речь ? ) , а вот предложенная выше реализация UnityOfWork работает только с группой репозиториев объедененных контекстом., на что я и обратил внимание с самого начала , с какой стати интерфейсы репозиториев вообще должны иметь какую либо привязку к "контексту". Ну , конечно , понятно какая там задача решается как и в прочих примерах , но это все очень узконаправленно , ограничено только репозиториями с контекстом , или еще хуже SQL репозиториями. Ладно , похоже пошли по кругу.

@m0nax · 13.01.2018, 17:17

ну и опять же , решаются узкие вопросы касательно EF и связанного с ним контекста , тем самым нарушая идеологию шаблона репозиториев. Они на то и абстрагированы интерфейсом , что реализация может быть для каждой сущности своя (БД , файл , облако) , и никакая узконаправленная специфика в виде контекста на этом уровне присутствовать не должна.

какая еще специфика? как раз наоборот репозитории создаются самые чистейшие по интерфейсам

C#

public class UserRepository : IUserRepository
{
    private readonly IAmbientDbContextLocator _contextLocator;
 
    public UserRepository(IAmbientDbContextLocator contextLocator)
    {
        if (contextLocator == null) throw new ArgumentNullException("contextLocator");
        _contextLocator = contextLocator;
    }
 
    public User Get(Guid userId)
    {
        return _contextLocator.Get<MyDbContext>.Set<User>().Find(userId);
    }
}

то есть никто не мешает создать второй репозиторий который будет получать из файла или облака, причем с тем же интерфейсом User Get(Guid userId), ведь вся завязка на БД происходит именно в конструкторе как деталь реализации
а созданием контекста и сохранением/коммитом управляет внешний код, который выше по стеку (обычно на самой вершине)
естественно там могут быть и распределенные транзакции и что еще нужно

@sau · 13.01.2018, 17:59

Тут уже столько понаписали , что начинается подмена понятий ). - нужно внимательно каждый пост прочитать , с самого начала.
Ото начали за здравие закончили за упокой.

Сообщение от m0nax

какая еще специфика? как раз наоборот репозитории создаются самые чистейшие по интерфейсам

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

Сообщение от m0nax

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

с такой постановкой согласен.

П.С
В приведенной Вами ссылке , в одном из интерфейсов встречается такая штука
TDbContext Get<TDbContext>() where TDbContext : DbContext;
где DbContext - это ограничивающая зависимость. , т.е библиотечка применима для определенного круга репозиториев.
Да , ваш пример репозитория вполне определенно использует DbContext , и может это делать не вынося этот момент на более общий интерфейс. Только , это все немного не в ключе обсуждаемого.

Но , возвращаясь к нашим баранам , с того , с чего начали:

C#

public class UnitOfWork : IDisposable
{
    private OrderContext db = new OrderContext();
    private BookRepository bookRepository;
    private OrderRepository orderRepository;
....
}

Может , все же , ближе к конкретике , поясните мне смысл этой конструкции ?
Во-первых , почему не IRepository<book> bookRepository ?, - какой смысл в шаблоне репозитория если мы не можем подменить реализацию ?
А если тут подставить интерфейс IRepository<book> , то мы не сможем работать через OrderContext db , поскольку на уровне интерфейса мы не имеем обязательств юзать какой либо контекст. Короче , очень сомнительная реализация.

@cunamy 7 / 7 / 1 Регистрация: 26.04.2013 Сообщений: 34
	10.01.2018, 06:55	2
	Вынеси логику из контроллера и используй репозиторий и паттерн UnitOfWork. https://metanit.com/sharp/mvc5/23.3.php Контроллера одного достаточно. 0

@Cupko 654 / 591 / 171 Регистрация: 17.07.2012 Сообщений: 1,680 Записей в блоге: 1
	10.01.2018, 17:25	3
	escoult, мыслите от модели: Созданием, удалением и редактированием модели Person, в том числе добавление телефонов для пользователя - для PersonController. Созданием, удалением и редактированием модели Phone, в том числе добавление пользователья для телефона - для PhoneController. Разница между добавление телефонов для пользователя и добавление пользователья для телефона в том, какую модель вы редактируете. 0

@escoult 1519 / 478 / 126 Регистрация: 09.01.2018 Сообщений: 1,237
	11.01.2018, 00:14 [ТС]	4
	cunami UnitsOfWork я не использую. Использую репозиторий с Generic Methods. Собственно, в этом случае, необходимость в UnitsOfWork отпадает. В данном, простом приложении вполне можно обойтись одним контроллером. Тут модель Phone мне точно больше нигде не потребуется. Но если это скажем большой магазин. Телефоны могут быть у клиентов, у поставщиков, у пользователей, еще у кого либо. Добавлено через 11 минут Cupko То же думал над этим. Но не додумал до конца. Как быть с вьюшками? Моделей две, какую вьюшку будет возвращать каждый контроллер? По идее, каждый свою. Но страница редактирования у меня одна. По крайней мере, для пользователя это должно выглядеть так. Открыл он какой то Person Details, хочет отредактирорвать. Но я не знаю, что он захочет редактировать. Может персональные данные, а может телефоны. Какую форму ему подсовывать? На странице, сколько бы у меня их не было, Submit все равно один. Как тогда должна выглядеть эта вьюшка, чтобы все поля модели были доступны для редактирования? Или все же по ссылкам его отправлять на контроллер той модели, которая редактируется? 0

@sau 2756 / 2059 / 384 Регистрация: 22.07.2011 Сообщений: 7,781
	11.01.2018, 13:11	5
	Сообщение от cunamy паттерн UnitOfWork. - это не паттерн , а антипаттерн от какого то индуса , один фигню написал , другие не думая подхватили. Но страница редактирования у меня одна ну так и вью.модель у нее одна, косвенно связанная с моделями данных. , т.е редактируется вью.модель , а затем раскидываете результат по нужным моделям данных и репозиториям. 0

@_exp10der_ Warrior 500 / 427 / 177 Регистрация: 23.11.2014 Сообщений: 932
	11.01.2018, 14:03	6
	Сообщение от sau - это не паттерн , а антипаттерн от какого то индуса , один фигню написал , другие не думая подхватили. Да ну быть не может. Microsoft так например не считает, со своей реализацией UnitOfWork в виде DbContext https://github.com/aspnet/Enti... ext.cs#L27 1

@Usaga 12505 / 8692 / 1310 Регистрация: 21.01.2016 Сообщений: 32,660
	11.01.2018, 14:47	7
	Сообщение от sau это не паттерн , а антипаттерн от какого то индуса Зря вы так. 1

@sau 2756 / 2059 / 384 Регистрация: 22.07.2011 Сообщений: 7,781
	11.01.2018, 20:14	8
	Сообщение от _exp10der_ Да ну быть не может. Microsoft так например не считает, со своей реализацией UnitOfWork в виде DbContext Ну ладно , тут вероятно можно по разному понимать реализацию паттерна , у мелкософта я не увидел криминала , а вот вариант по ссылке на метанит мне совершенно не понравился. Если следовать определению: Обслуживает набор объектов, изменяемых в бизнес-транзакции (бизнес-действии) и управляет записью изменений и разрешением проблем конкуренции данных. зачастую реализация сводится к обычному сервису данных , который инкапсулирует в себе логику работы с интерфейсами различных репозиториев. И кстати , кто сказал что в майкрософт индусы не работают ? ) , приведенный пример реализации на метаните уж очень узконаправленный , сразу несколько сущностей тесно связываются общим Db контекстом ,в итоге теряем гибкость и возможность изменить для этой группы тип репозитория (скажем не SQL и не EF) , в то время как паттерн репозитория с этой целью и реализуется. Его конечно можно допилить , реализуя абстрактный контекст и т.п , но это все проще решается. 0

@m0nax 1274 / 975 / 113 Регистрация: 12.01.2010 Сообщений: 1,971
	12.01.2018, 22:31	10
	А я использую https://github.com/mehdime/DbContextScope Тихо мирно у себя в углу считаю это "серебряной пулей" в плане доступа к данным, у автора гигантская статья в которой описаны все возможные варианты их плюсы и минусы (я сам половину из них использовал и согласен) он учел все "наивные" реализации IRepository и IUnitOfWork которым забит интернет и несколько прочих вещей и вариантов (да и я тоже) бесконечно гибкая вещь, хоть 2-3 контекста, хоть репозитории(идеально вливаются), хоть напрямую используй контекст в кастомных сервисах так же годится как для для специальных мест где критична производительность, так и для специальных мест где критична транзакционность - ногу отстрелить не дает (поначалу бесит правда, но ведь он прав(!!) 2 save быть не должно никогда) а ну и да я уже 3 раза использовал либу в боевых проектах, 2 кровавый энтерпрайз 1 домашний, либа и ее идеология выдержала всё без каких-либо серьезных проблем, хоть веб, хоть обычные окна 2

@sau 2756 / 2059 / 384 Регистрация: 22.07.2011 Сообщений: 7,781
	13.01.2018, 15:58	11
	Сообщение от m0nax А я использую https://github.com/mehdime/DbContextScope ну и опять же , решаются узкие вопросы касательно EF и связанного с ним контекста , тем самым нарушая идеологию шаблона репозиториев. Они на то и абстрагированы интерфейсом , что реализация может быть для каждой сущности своя (БД , файл , облако) , и никакая узконаправленная специфика в виде контекста на этом уровне присутствовать не должна. Тут , при необходимости , должен использоваться механизм распределенной транзакции , реализация которого уже зависит от обстоятельств. А вот внтури уже конкретной реализации репозитория - который совсем не обязательно может быть элементарным , уже можно применять всякие контекстно зависимые штуки вроде DbContextScope или UnitOfWork, там они правомерны т.к решают задачу в своем контексте. 0

@Usaga 12505 / 8692 / 1310 Регистрация: 21.01.2016 Сообщений: 32,660
	13.01.2018, 16:02	12
	sau, как-то я с вами не согласен. Идея "контекста" ни как не диктует способ хранения данных. 0

	13.01.2018, 17:59

@Usaga 12505 / 8692 / 1310 Регистрация: 21.01.2016 Сообщений: 32,660
	13.01.2018, 16:21	14
	sau, ну, "контекст" выступает в роли контейнера репозиториев. Совершенно не обязательно, что он (контекст) должен быть в одном лице. То, что он не везде нужен - спору нет. Это очередная абстракция для более-менее сложных проектов. Но сама идея контекста не диктует правила хранения данных 0

@sau 2756 / 2059 / 384 Регистрация: 22.07.2011 Сообщений: 7,781
	13.01.2018, 17:10	15
	Сообщение от Usaga sau, ну, "контекст" выступает в роли контейнера репозиториев. по вашим словам и по вышеизложенному , получается , что он группирует схожие по принципу работы репозитории , скажем DbContext группирует SQL репозитории. А если репозитории принципиально разные - будет несколько разных контекстов , но которые все равно может понадобиться выполнить в рамках одной транзакции , и в таком случае , вероятно , смысл дополнительной абстракции в виде контекста пропадает. В общем , все зависит от решаемой задачи , как всегда. Сообщение от sau "контекст" выступает в роли контейнера репозиториев. Все же я немного не понял этот момент. , скорее наоборот , контекст присутствует как частный случай в одной из конкретной реализации интерфейса репозитория , для его внутренних нужд , или мы о каком контексте ведем речь ? ) , а вот предложенная выше реализация UnityOfWork работает только с группой репозиториев объедененных контекстом., на что я и обратил внимание с самого начала , с какой стати интерфейсы репозиториев вообще должны иметь какую либо привязку к "контексту". Ну , конечно , понятно какая там задача решается как и в прочих примерах , но это все очень узконаправленно , ограничено только репозиториями с контекстом , или еще хуже SQL репозиториями. Ладно , похоже пошли по кругу. 0