hVosttМСУ,

а вы смешной. врете как мерин, что читали фаулера, зачем врать не понимаю. знаете всего по чуть-чуть, где-то в районе верхушки айсберга. показываете примеры для даунов, скопипащенные с каких-то учебных мануалов, но хотя да — можно делать и хуже.
Мне фиолетово мнение бездумного линейного кодера, который не понимает сути, которую ему вменяют.
Скопипасщенные примеры, всё же, у тебя - тупое дублирование репозитория с не менее тупым размазыванием абстракций в реализации контроллеров. Да, можно делать и хуже.


hVostt какие вы там сервисы готовите подменять? куда? на что? зачем? что за бредятина? с горячей сменой дата-сервисов вообще другие подходы применяются, даже не такие, что я предлагал (мой ориентирован на TDD). но вы бы знали о них, если бы вы читали проф. литературу, и такой бред бы не несли под видом знатока (кстати, очки поправьте).
Ты просто уныл своим мартышкиным мышлением, десять раз повторил про жизненные реалии, когда требуется 10% слоя данных брать из других источников. Пример реален как сама жизнь, просто опять же, ты не имеешь опыта работы. Потому что ты глупая кодеманка, коих тыщи. На тебе можно пахать, заправляя в узды. Но на что-то более ты не способа.

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

Где-то в степия например не согласен с мсу в плане орм слоя
Готов выслушать альтернативные аргументы. Для меня главное в этом слое - полностью отвязаться от конкретного поставщика данных (ORM, SOA, XML, ... etc). Контроллер через IDataService оперирует дата-моделями (дополнительная прокся от ORM, SOA, XML, ... etc), использует их в моделях представлений (некий примес MVVM подхода) и честно подсовывает это во View. Гибко и отвязанно от конкретного поставщика данных? Да.

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

SeVaМСУпропущено...


Идём далее. Тут давеча я приводил пример, что через некоторое время может поменяться поставщик для определенных справочников - через акспату. Например, 90% логики остается такой же, 10% - переписывать на WCF-сервисы из акспаты.
Гавно вопрос: создаем новый датасервис AxaptaDataService и наследуем его от SqlDataService, 10% методов переписываем через override, всё остальное у нас работает как часы. Поэтому при смене источника для определенных сущностей мы тупо переписали только 10% методов,наследование рулит. Поддерживать такую архитектуру одно удовольствие.

1.Какой-то бред, придуманный на ходу или для заполнения говносайта с детскими рецептами.
CategoryModel - явно не обобщенный вариант, а конкретная модель для Категории.
У тебя что 10% Категорий лежат в Аксапте.
2. Интерфейсы были придуманы для того, чтобы уйти от косяков с наследованием. Завтра понадобится еще 10% для 1С, послезавтра
20% для интеграции с другими системами. А через год требования для базовой SqlDataService изменятся так, что они совершенно не будут стыковаться с другими. Наследования для подобных вариантов - полная хрень с обязательными граблями в будущем.
1. Бред у тебя в мозгах, а тут датасервис. 10% методов (категории и продукты) переносятся в аксапту. Пишем новый датасервис с переопределением 10% методов.
2. Интерфейсы были придуманы не для ухода от косяков, а для наследования с обязательностью реализации контракта. сюда можно закладывать не только 1с, но и данные из космоса, вся логика будет работать так же на тех же рельсах.

SeVaМСУпропущено...

В большинстве случаев (а их 99%) достаточно ручной инстанциации экземпляра (IProjectRepository) - через конструктор базового контроллера. У тебя он отсутствует.




В IDataService - только IEnumerable , никаких квери и еще что-либо.




По причине того, что мы можем подключить сторонний датасервис, например, XmlDataService, который ничего не знает о трансляции SQL. IEnumerable - это бест практис.

пропущено...

Как решается эта задача - в IDataService:




Всё. А в своём SqlDataService или XmlDataService делаешь реализацию.

Из контроллера:




Идея понятна?

P.S. Слишком много инъекций с ресолвами, код выглядит загаженно и удручающе. В моем случае - код чистый, инкапсуляция рулит.

1."Ресолвы" только у тех кто не имеет никакого понятия о DI контроллерах, которые инжектят зависимости автоматически.
В результате код самый чистый.
2. При переписывании бредовых 10% процентов ты еще будешь своими грязными руками лезть еще в контроллеры, а в случае с DI нет.
Ты так нихрена и не понял, контроллеры не меняются, они остаются такими как были. Меняется только датасервис.

SeVaМСУпропущено...

1. Бред у тебя в мозгах, а тут датасервис. 10% методов (категории и продукты) переносятся в аксапту. Пишем новый датасервис с переопределением 10% методов.
2. Интерфейсы были придуманы не для ухода от косяков, а для наследования с обязательностью реализации контракта. сюда можно закладывать не только 1с, но и данные из космоса, вся логика будет работать так же на тех же рельсах.


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

SeVaМудафаил, твои датасервисы(очередной левый термин, Фаулер ты наш местного разлива) пригодны только для школьников.

Любое бизнес-приложение(говносайтики на несколько страниц для которых пригодны мембершипы с тремя ролями не в счет) - достаточно ограниченный набор сценариев: открыть\отфильтровать список, создать\редактировать единичную запись, etc.
Для них возможно написание обобщенных контроллеров a'la Controller<TModel>, переопределив resolver для Сontoller'a в купе с DI можно забыть об их создании и ручном кодировании.
Для того, чтобы был общий вариант нужно использовать ViewModel, которые ты не осилил, тк это более общий вариант и часто требуется агрегация данных и дополнительные сущности для создании ViewModel и View.
При таком подходе все разделено, рисуем View, иногда переопределяем контроллеры и\или ViewModel
Ты просто унылый ушлепок без грамма сознания - почитай про идею mvp подхода. Обобщенный контроллер нужен только таким кретинам как ты, в асп нет мвц за инстанциацию контроллера отвечает ядро. Ты просто унылый арангутанг, который ничего не понимает в мвц.

hVosttМСУ, даже если все человечество ткнет тебя носом в твой грязный код, ты все равно останешься при своем. такое упорство как минимум заслуживает уважения :) но из программеров я бы тебя выгнал. наверное твоя кандидатура хорошо бы смотрелась среди маркетологов. но не среди программистов, и уж тем более проектировщиков.
Уж извини, но читать что-то про кандидатур программистов от таких как ты смешно, которые никогда не работали в команде, которые REST называют архитектурой, вещают о том, что все сервера работают REST. Только шизофреник может такое ляпнуть. Про WebForms и небесную ману я вообще поржал - порог вхождения в технологию самый низкий, а для тебя нужно быть каким-то магом, что-бы всё хорошо получилось. Ты просто неотёсаный пионер, которому вкормили на работает старшие товарищи порцию навоза. Ты тупо бездумно проглотил эту хрень, ничего другого принимать не желая. Банальная кодеманка, кули тут еще сказать.

hVosttвидимо тебе как маленькому ребеночку надо пояснить, в чем же ты заблуждаешься
Тебе нечего объяснять, ибо твоя дегенеративная ветвь мышления - утопична.

hVostt1. в каждом методе твоего "датасервиса" вот такая штука: using(var db = new MyDbContext). возможно, не каждый метод сервиса создает новый контекст. это типа позволяет переписать сервис, заменив только те методы которые зависят от контекста. но чтобы переписать эти методы, надо знать какие . разделение ответственности мы похоронили без музыки и цветов.
И правильно - каждый метод самодостаточен для получения данные, он и рулит жизью экземпляра датаконтекста. Если это будет XML - значит будет использоваться XmlDocument или XDocument во всеми вытекающими. Вытаскивать наружу MyDbContext (например, через генерик датаконтекст или просто в конструкторе) нет смысла, потому что датасервис может обращаться к различным базам данных. Так же нет смысла вытаскивать наружу MyDbContext для тестирования, так как там тестировать нечего. Зачем тебе тестировать автогенеренный MyDbContext от EF? Поэтому ты вволе им управлять в методах. При большом желании всё-таки никто не запрещает его вытащить на уровень конструктора, дело желания.

hVostt2. за использование наследования для тупого прокидывания объекта сервиса/контекста/репозитория, надо отрубать руки, по самую голову. у контроллера не должно быть базового контроллера, если он только не реализует общую логику для всех контроллеров. предоставление объекта сервиса — это не логика. этим должен заниматься внешний контейнер.
За не использование наследования и тупое размазывание интерфейсов в прикладных контроллерах нужно выкачивать мозг, напрочь. С последующей заливкой керосина. У контроллера должен быть базовый контроллер и логикой он не должен заниматься априори. За такие слова тебя Фаулер лично бы четвертовал - за тупость и кретинизм. Никому не рассказывай про этот бред.

hVostt3. датасервис ничего не должен знать про MyDbContext. и, поэтому, не должен создавать его инстансты напрямую. таким образом можно вообще убрать контекст из проекта, или заменить контекст на другой, подсунуть его адаптер или прокси. также можно не писать заглушки вручную в процессе разработки, используя моки. что очень хорошо. подход с using(MyDbContext) плох, грязен, и отвратителен.
Датасервис должен всё знать о датаконтексте, я уже говорил - твоё дублированное расслоение и прокидывание IQueryable - сплошной воды утопия на чистом месте. Датасервис сам является адаптером, поэтому ему не нужна еще какая-либо абстракция.

hVostt4. датасервис нужно разделять на зоны ответственности. тогда все части можно будет разрабатывать совершенно независимо, имея на руках только доменную модель интерфейсов. тогда будет разделение работы, и поголовное счастье. и никакого большого IDataService на весь проект — это форменное издевательство, если проект чуть больше, чем "Hello World!"
Сами датасервисы - независимые компоненты приложения, которые стыкуется с ними по IDataService. Что ты там еще хочешь разделить, непонятно. "IDataService на весь проект" - это бред твоего воспаленного воображения, а я такого не говорил. У тебя могут быть 100500 датасервисов, у каждого свое предназначение.

hVosttП.С. ответ по-большей части написан не для МСУ, так как этот товарищ обязательно спустится на уровень "ты тупая обезьянка", на котором мне не о чем с ним говорить вообще, а для тех, кому интересна обсуждаемая тема на адекватном уровне.
Тебе рано еще говорить об адекватном уровне, рано.

Кстати, эта идеология IDataService в контроллере отлично ложится и на WebForms (в контексте презентера): ASP.NET Supervising Controller (Model View Presenter)

iConstСкладывается впечатление, что его основные оппоненты, в силу каких-то причин, более приближены к конкретной реализации. Отсюда и сыр-бор...
Потому что я практик , а не теоретик, как мой голословный оппонент, который даже не имеет опыта командной разработки :)