МСУ,




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

зачем отдавать вью квери и параметры сортировки? ну, например, хотя бы потому, что вью может выбрать столько, сколько нужно и отсортировать в соответствии со видом и назначением вью (например, параметры сортировки для атома всегда одни и те, же в независимости от того, что там хочет контроллер)

представленный выше пример достаточно примитивный, конечно в реальном большом проекте фильтры/сортировки инкапсулируются в отдельные структуры, и во вью отдаётся специальный моделвью

но в использовании iqueryable ничего плохого нет, я считаю. так как сломать данные (базу) нельзя, отсутствует доступ к контексту и к unitofwork, все что можно делать, это сортировать и фильтровать. но при развитии проекта, iqueryable все реже перепадает вью.

я знаю, что различные гуру советуют все упаковывать во вью модель и только так. не согласен с ними. заочно не согласен с любыми позициями, где фигурируют слова «только вот так, и никак иначе» :)

МСУhVosttef, например как раз и предоставляет айквериэйбл, типа микроконтроллера. никакого доступа к орму нет. только легкое ненавязчивое управление выводом.
1. Еще раз не совем понятно, что за "ненавязчивое управление выводом" и в каком слое оно реализовано?
2. Какой-такой микроконтроллер? :) Ты, наверное, рассуждаешь о неком IService или фабрике? Опять же, в каком слое?
3. Давай всё по-порядку, рассмотрим 3 слоя: модель, представление и контроллер (можно четвертый слой ввинтить - модель представления).

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

микроконтроллер, я так называю некоторые самодостаточные интерфейсы, IEnumerable и IQueryable вкупе с LINQ одни из них. т.е. универсальные сервисы. еще это могут быть всякие IPageable, IRoleable....

то, что эти насквозь прошивают «великую и могучую» MVC не нарушает её принципов, если не нарушают принципов независимости и самодостаточности. как говорится, не плодите лишних сущностей :)

МСУ,

нееет, батенька )) про 99% разработчиков, не применяющих TDD вы конечно загнули. ладно, забьём на тесты, русские тру-кодеры хотели покакать на это ваше тестирование с большой мариуопольской вышки.

кейс №1. базовый контроллер — это плохо. это действительно плохо, так как рулить контроллерами должна фабрика, а не инкапсуляция. а мало ли чего (мы же забыли про тесты, та?). если хотябы фабрика своя и она даёт датасервис каждому контроллеру... ну это вообще жуть. получается каждый контроллер де-факто имеет доступ ко всей дата бейз? ну и ну.

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

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

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

handmadeFromRu,

потому что у UoW одна задача — сделать дать сделать коммит (или не дать). ради чего в этот вов пихают свои сервисы и репы не пойму.

МСУ,

и эта.. IDataService это не абстракция )) это весьма конкретный дай-сюда-это, возьми-вот-это, сделай-как-то-так. интерфейсом зовётся. ну если только это не обстракция в виде:

IDataService {

MyDbContext Context {get;}

}

МСУhVosttМСУ, нееет, батенька )) про 99% разработчиков, не применяющих TDD вы конечно загнули.
Я ничего не говорил про "неприменение TDD". Мой "вариант" так же легко можно тестировать.

хотел бы я на это посмотреть.

МСУhVosttкейс №1. базовый контроллер — это плохо. это действительно плохо, так как рулить контроллерами должна фабрика, а не инкапсуляция. а мало ли чего (мы же забыли про тесты, та?). если хотябы фабрика своя и она даёт датасервис каждому контроллеру... ну это вообще жуть. получается каждый контроллер де-факто имеет доступ ко всей дата бейз? ну и ну.
1. Ну так рули в базовом контроллере, хоть руками, хоть через фабрику. Какая принципиальная разница? Зато я не размазываю эту логику в самих прикладных контроллерах. Даешь чистый контроллер!
2. Каждый контроллер де-факто не имеет доступ ко всей дата бейз, каждый контроллер де-факто имеет доступ своему IDataServive. Почувствуй разницу.

получается, вы размазали свой код не вдоль, а поперёк. Действительно, какая принципиально разница? Вы выиграли только визуально (меньше кода в контроллере отображается), но функционально.... в общем дабы избежать долгого спора, раньше я именно так и делал (как вы) :) вот практически один в один, базовый контроллер, большой дата сервис (обстракция!). но потом пришло время расти. надо было 100% тестирование. это не шиза, это реальное условие заказчика (к вопросу об условиях заказчика, в особенности зарубежного).

МСУhVosttпоехали дальше. почему репа и сервис — вещи разные. потому что репа, это инстанс дженерика почти во всех случаях.
Чё-то я нифига не понял, еще раз - причем тут вообще дженерик? Репозиторий так же не обязан быть дженериком.

это я к слову сказал. но чтобы было понятней: Repository<TEntity>: IRepository<TEntity>... скафолдинг и кодогенерация (а ручки-то вот они где)

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

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

МСУhVosttедем дальше. наконец, кейс. реальный! жил-проект. у него все было в одной базе и все было круто. потом вдруг этот проект попадает в стек других проектов, где есть своя база данных пользователей, ролей и прочей профильной фигни. как же это решается? ничегошеньки переделывать не надо. пишется реализация IUserRepository, подсовывается в депенси ресолвер. в итоге, ни один контроллер, ни один сервис, ни один фильтр не почувствал разницы. ок? заказчик доволен, программеры в экстазе. все решилось быстро и без нервотрепки.
Так у меня точно так же, пишется свое реализация IDataService (например, был SqlDataService, а стал WcfDataService или XmlDataService). Потом в базовом конструкторе кентроллера мы подключили наш новый сервис и всё стало так же работать (через абстракции IDataService). Ты читаешь как-то между строк, что-ли? Или я пишу непонятно :)

вы лезете в конструктор контроллера и что-то там меняете, чтобы сменить сервис. и после этого вы мне говорите, что ваше решение готово к TDD? вы издеваетесь?

МСУhVosttну и на последок. ладно вы отдаете в контроллер инстанс датасервиса через базовый класс. а кто отдает этот инстанс различным фильтрам? в том числе глобальным?
Выражайся по-русски, инопланетяне сейчас не в моде. Какой фильтр? Что такое глобальный фильтр, ты о чем вообще?[/quot]

ActionFilter, ActionFilterAttrribute, AuthorizationFilterAttribute..... etc.

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

вот репозиторий:




репы для остальных сущностей делаются так




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

а вот сервис, это такой умный братан репы, который знает много контекстно-зависимых слов:




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

handmadeFromRuМСУ эт я hVostt вопрос адресовал)

hVostt,
ну да но uow и репо близки. честно ...чет я сам запутался. загуглил сюды
http://stackoverflow.com/questions/7940854/is-unit-of-work-and-repository-patterns-very-useful-for-big-projects

uow - это типа буфера для команд обновления БД
репозиторий - это ОО интерфейс к данным. он же отслеживает изменения в модели и выдает команды к uow
фишка в том, что все крупные ORM - это UoW + Repository

собственно из-за этого и спросил про зачем они вместе лежат
по мне EF + тонкий интерфейс над ним - вот и все, что нужно. или вам надо сделать абстракцию над орм? ...я думаю переезды на другую орм ..я хз событие как конец света - редкое, но веселое)!

п.с. надеюсь я еще адекватен и не в бреду и правильно понял) даешь пятницу в среду!!!

у EF DbContext это UnitOfWork. но мы делаем свой UoW, поверх него. задача у него одна, принципиальная. в контроллер мы никогда не прокидываем DbContext. а сохранять данные как-то надо. прокидываем IUnitOfWork, у которого есть Save (или Commit, кому как нравится). да, он может много чего еще. отслеживать изменения данных, вешаясь на определенные события, если надо. в общем, действовать как транзакционная машина, обрабатывать программные триггеры.

ну и самое главное. если в контроллере нет IUnitOfWork, значит он гарантированно 100% ничего в базу не сохраняет. только берет. это важный в разработке ньюанс. на самом деле приведенный выше код, это не «много грязи в коде», это кристальная ясность относительно того, что контроллер делает. а если контроллер чист, типа все ему передается через базовый класс, то не понятно ничего. надо копать. в большом проекте ковыряться для выяснения обстоятельств, — нудное и безынтересное занятие.

МСУhVosttхотел бы я на это посмотреть.
Гавно вопрос, выложил сюда подход: http://codearticles.ru/Home/ArticleView/2155
Посмотрю сегодня вечером, о результатах отпишусь :-)

МСУhVosttполучается, вы размазали свой код не вдоль, а поперёк. Действительно, какая принципиально разница? Вы выиграли только визуально (меньше кода в контроллере отображается), но функционально....
1. Визуальность рулит, дружище. Смотреть в каждый код на тонны гавнокода, гвоздями прибитого к фабрикам, репозиториям, датасервисам... Бррр. Вспомни о трёх китах объектно-ориентированного программирования :)
2. Функционально я не проигрываю, сколько раз тебе объяснять, могу еще раз объяснить это. Ты просто помешан на резолвах в локаторах, а я объясняю, что в большинстве случаев и инстанция подойдет - главное, что она в одном месте . Зачем мне 100500 резолвов, размазанных в 100500 контроллерах, если я один раз в базовом контроллере инстанциируюсь и все унаследованные контроллеры получат своего поставщика.

1. Никакой тонны. Я смотрю на то, с чем работаю. Вижу IUnitOfWork, значит понимаю, что могу сохранять данные. Вижу сервис с определенным названием, значит знаю какую область я решаю. Хорошо, когда помнишь. Плохо, когда уже подзабыл, или вас несколько человек работает над одним проектом. Абсолютно ничего лишнего. Я вижу с чем работает контроллер, а не лажу в базовый класс, чтобы разобраться что мне оттуда приходит. В этом и прелесть, дружище :)
2. Она у тебя в базовом контроллере. Считаешь, это лучшее место для управления жизнью инстансов, которые могут понадобиться еще и за пределами контроллера (фильтры, например)?

МСУ... Но главный его плюс - это его чистота, посмотри в примере в аттаче и сравни со своей "грязной" реализацией.
про тестирование, вечером гляну. а вот грязи никакой нет. класс самодостаточен, я вижу что он получает при создании (конструктор), вижу что он хранит. я могу создать такой контроллер отдельно, вообще в другой сборке. это самый чистый контроллер из всех.

МСУhVosttэто я к слову сказал. но чтобы было понятней: Repository<TEntity>: IRepository<TEntity>... скафолдинг и кодогенерация (а ручки-то вот они где)
На свалку, ибо Repository может зависить от n entity. А если у на 2 БД, плодить два репозитория и делать 2 подключения к БД? :) У меня же IDataService более "абстрактен", к нему можно прибить 2 базы данных (по сути это одно хранилище, разнесенное по базам - так, к примеру, шарепоинт работает), а на выхлопе использовать родные сущности. И всё это счастье за единый коннекшен (в твоем случае их будет уже два). Кстати, один из минусов ORM это то, что они прибиваются к одной БД в разрезе контекста. Последствия сам понимаешь какие. Я же всегда могу обойти это в своем слое (на ридерах вмапиться в прокси классы) за одно физическое соединени к БД.

мда... :) мы похоже забыли про прослойку EF, которой можно отдать другой провайдер данных в конфиге, или другую строку соединения. речь идёт о принципиальной смене поставщика данных. DbContext там не катит. поэтому приложение ничего не знает об это контексте. он работает только с сервисами и репами.

МСУЯ ж говорю, меняй стереотипы, иначе так и помрешь в неведении ))

а вы... а вы.. )) уничтожаете мои стереотипы, как не стыдно!

МСУНикто не мешает управлять точно так же через резолвинг через тот же автофак. Зри в корень, а не плавай на поверхности.

ну если так, другое дело. просто вы говорите, можно, но так не делаете. значит для TDD вам потребуется подгонка проекта. ну может вам перепадёт заказ со 100% тдд, а вы их окрестите шизой ))

МСУhVosttActionFilter, ActionFilterAttrribute, AuthorizationFilterAttribute..... etc.
См. выше, ты можешь управлять экземпляром в единой песочнице и подсовывать ее в базовый конструктор, фильтры и иже с ним.

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

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

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

МСУhVosttа вот сервис, это такой умный братан репы, который знает много контекстно-зависимых слов:
Говорю же, лишнее расслоение. В моем случае я создал бы новый IProjectService и научил бы его последователей всему тому, что требуется.

звучит как будто из уст проповедника )) идите мои браться, да распространится знание по миру!

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