Вот тут рассказал: http://codearticles.ru/home/articleview/2296?comment=61

Реализация IDataService подхода в ASP.NET MVC4

Без базового контроллера нонче никак.

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

Любой контроллер может юзать инстанс датасервиса, что тебе не нравится? Кроме плохо и фуфу арументы еще будут?

http://code.google.com/p/mvc-authorization-authentication/source/browse/trunk/+mvc-authorization-authentication/MVCAuthenticationSample/BaseController.cs

Классическое применение базового контроллера, о котором я говорил тут . Правда, я бы не совсем так писал секурити, я б вынес это в отдельный класс, который прибыли к базовому контроллеру. Но не суть.

hVosttM — это бизнес-логика, куда входит модель и все операции над ними.
C — это прослойка между M и V.
V — это по сути тупейший шаблон вывода данных.
Тогда непонятно, как же ты предлагал вести логику CRUD в контроллере. Ты перечишь сам себе

hVosttПоэтому никакую логику C не должен инкапсулировать.
Хотя никто никому не может запретить откровенно говнокодить.
См. выше.

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

hVosttТогда небыло глобальных фильтров. Нужна какая-то обработка для всех действий независимо от контроллера? У MVC для этого есть точки расширения, такие как глобальные фильтры например.
Никак не возьму в толк, как коррелирует GlobalFilter и банальное наследование. Во-вторых, "тогда" - это когда? GlobalFilterCollection существуют аж с 3 версии MVC.

hVosttНе отрицаю, что в большущем проекте какой-нибудь супер-CMS может понадобиться собственная реализация контроллера и то, если это не нарушает принципов единой ответственности и не повышает связность в архитектуре.
Если не отрицаешь, то в чем, собственно, вопрос?

hVosttПодача данных — ошибка проектирования однозначно.
Как может наследование и инкапсуляция быть ошибкой проектирования?

hVosttВ ASP.NET MVC есть встроенная инфраструктура разрешения зависимостей. Не нужно её игнорировать, если лень разбираться, то тут уже ничего не поделаешь.
Раскрой тему подробнее, о чем именно речь.

hVosttУ меня осталось на поддержке 2 проекта, где я по неопытности и незнанию делал один в один, как предлагает МСУ, т.е. базовый контроллер, передающий своим наследникам Service. Это ад. Залез в код через несколько месяцев и не имею представления о том, какой контроллер работает с какими данными, какие контроллеры меняют данные, а какие не могут.
Ты уже достаточно "по опытности" нам показал, как работать с обработкой исключений. Во-вторых, что значит "не имею представления о том, какой контроллер работает с какими данными"? Если ты дурак и не разбираешься в C#, то не имеешь. Как можно читать код контроллера и не понимать, с какими данными он работает? Бред сивой кобылы.

hVosttИбо все контроллеры имеют доступ ко всем данным и могут делать с ними что угодно. Это плохо, плохо, и еще раз плохо. Это не гуд. Чугунной линейкой лупить по рукам за такую архитектуру.
Контроллеры, отнаследованные от базового, не "имеют доступ ко всем данным", а имеют доступ к общему датасервису (датасервисам). Почувствуй разницу. Во-вторых, с какими данными и как работать - не задача контроллера, а задача отдельного секьюрити класса, который доступен во всех контроллера. В-третьих, о архитектуре тебе еще рано судить, не дорос.

hVosttПоследние мои проекты используют по возможности всю мощь MVC, в том числе DI и DepencyResolver, сказка. Пока не нашлось ни одной задачи, которая бы решалась лучше всего через базовый контроллер. Все покрыто тестами, на все 100%, при разработке не используется база данных, данные генерируются так как мне надо.
Ситуация с базовым контроллером не запрещает использовать зависимости, твой фанатизм мне непонятен.

hVosttПотом легко сборка с DataAccessLayer подменяется на EF.
Вот тут рассмешил, ты еще не научился с EF работать, какой еще тут DataAccessLayer :) Во-вторых, сборка легко подменится и с ситуацией датасервиса, который интерфейсом доступен для всех контроллеров. В чем профит?

hVosttНикаких изменений в коде проекта не производится. Сказка. Нет нужды лезть и ковырять базовый контроллер, чтобы сменить полностью всю бизнес-логику. При чем менять можно не только базу данных, но и вообще весь слой доступа к данным.
Какая разница, куда лезть, в базовый контроллер или в класс, управляющий жизнью инстанса?

hVosttskyANA, речь сейчас не идёт о какой-то конкретной задаче.
Тебя пытаются вывести из сумрака и подогнать конкретную ситуацию. Речь именно о конкретной задаче.

hVosttв примере с компонентом/виджетом CMS есть смысл.
А нахрена ты тут морг всем насилуешь и срешь в моих камментах? (сцуко, забаню нахрен)

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

hVostt, и ты задрал уже флудить в камментах! Если по сути рецепта нечего по сути сказать - проходи лесом.

hVostt1. ссылку на говнокод который ты мне скинул датируется 2009 годом . а ASP.NET MVC 3 RTM has been released January 13, 2011 . так что про глобальные фильтры совсем не в кассу. в стабильные привычки, смотрю, у тя входит скинуть ссыль на первую попавшуюся выдачу из Google, не разобравшись даже с тем, что скидываешь.
В примере приводится демонстрация функционала, доступная в базовом контроллере, а именно секурность - HasUserAccessToModule, о которой я говорил тут 14144190 . Расскажи нам, как собираешься подобное реализовывать в глобальном фильтре? Побежал за попкорном.

hVostt2. к вопросу «Как может наследование и инкапсуляция быть ошибкой проектирования?» , отвечаю: какая нахрен инкапсуляция??? ребенок, ты чо несешь? иди открой справочник на слове «инкапсуляция» и прочитай что это хоть значит. я уже не понимаю, ты вообще программированием как занимаешься? просто выучил ряд терминов, а что они значат знать совсем не обязательно? ну и ну...
Тем неучам, кто не обрабатывает исключения в приложении и говорит, что у него никогда не падает код - не понять. Разжевываю для тех, кто в танке. Вот тут 14144190 я писал:
...МСУКлассическое применение базового контроллера, о котором я говорил тут. Правда, я бы не совсем так писал секурити, я б вынес это в отдельный класс, который прибыли к базовому контроллеру. Но не суть.
То есть - секьюрити инкапсулировано в отдельном классе, отруливающим что можно делать пользователю. Сам класс прокидывается в базовом контроллере и доступен всем наследникам. Шагом марш в школу, недоросль.

hVosttпоясню для маленьких деток. твой датасервис, который размещается в базовом классе с таким же успехом может быть доступен 1) из MvcApplication, 2) из собственного синглетона, 3) из ServiceLocator-а 4) и т.д., а проброс доступа к данным (как ты там его называешь, Service?) из базы в наследника к инкапсуляции не имеет никакого отношения.
Ты даже уже не помнишь, о чем шла речь - не мудрено. Сначала иди почитай, что такое EF и логирование в приложении, а потом мы поговорим за инкапсуляцию. Речь шла о секурити классе, бестолочь (наследование + инкапсуляция).

hVostt3. к комменту «Раскрой тему подробнее, о чем именно речь.» берем первую попавшуюся книгу про ООП и постигаем что такое ООП, для чего он нужен, где применяется. потом открываем книгу про паттерны программирования и читаем, читаем, читаем.... потом уже изучаем ASP.NET MVC и узнаем, что (ничего себе!) он из коробки поддерживает аспектно-ориентированное программирование, да еще реализует ServiceLocator (предоставляя интерфейс IDepencyResolver), а с одним из популярных контейнеров еще и получаем DI. учим зачем и почему этот оверхед в коде нужен, что это даёт и к чему может привести сильная связность компонентов приложения.
А теперь подумай своим унылым мозгом, причем тут наследование? Или ты хочешь сказать, что с появлением IDependencyResolver в MVC отпала надобность в наследовании? Бред сивой кобылы, которая ничего не понимает в IoC и ООП - в кучу смешалось всё, люди, кони...

hVostt4. просто включи мозг. как ребенок, ей богу. ясен пень, что прочитав код контроллера, станет понятно с чем он работает. но будет на много лучше, если это же самое будет понятно всего лишь глядя на его конструктор.
Ты как доходяга - кто тебе запрещает использовать конструктор базового контроллера? Протаскивай там свой entry point в виде IDataService и инициализируй свойство. Тебе кто-то связал руки?

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

hVostt6. приехали. занавес. значит, между доступом «ко всем данным» и «к общему датасервису» какая-то фантастически-космическая разница есть, а тут разницы нет. мдаааааааааааа...
Ничего не понял, опять какой-то поток феерической фантазии. У тебя сложности с построением предложений? Еще раз и по порядку.

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

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

hVosttвопрос был поднят, вопрос. не может ли обернуться на первый взгляд видимое удобство быстрого доступа к объектам просунутое через базовый контроллер, проблемами в сопровождении
Не может. Был не просто поднят вопрос (иначе тебе просто ответили бы), а были высказаны тобой бредни про сферического коня в вакууме с метанием слюны про DI и прочий шелест листьев об ООП. Почувствуй разницу между "вопрос был поднят, вопрос".

[quot hVostt]МСУ,

Вот те на, пожалуйста, ребенок:



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

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




Базовый контроллер - лишь удобный проводник для логики безопасности:




Всё. Теперь мы можем удобно отруливать свойством Security во всех контроллерах и представлениях (через ViewContext.Controller) без каких-либо телодвижений с моделями представлений.

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

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

Читай книжечки всяких Фрименов и Экспозито, МСУ, практикуйся, учись. Верю, у тебя все получится. Когда-нибудь до тебя допрет, что говнокод к хорошему не приводит.


Дурилко картонное, как мне с помощью твоих фильтров отстроить UI в разрезе пользовательских прав? Тебе не то, что Экспозито, тебе программировать противопоказано, теоретик.

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

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

hVosttпредпочти слабую связность наследованию. агрегацию, резолвинг, аспекты. это все лучше наследования, практически всегда. если только ты не разрабатываешь фреймворк. тогда я спорить не буду. а покажешь своё детище еще и спасибо скажу.
Для каждой задачи - своя отвертка. Ты же пытаешь подо всё подогнать молоток. Это лишь говорит об отсутствии реального опыта - просто унылая кодирующая обезьянка, которая смотрит как дяди пишут. Тебе дали реальную задачу - ты начал что-то булькать невнятное. Потом ты начал плести бред, что да, базовый контроллер нужен. Теперь ты несешь бред про DI. Ты определись, чудо, больно смешно смотреть на твои рыпанья.

hVosttМСУТы как доходяга - кто тебе запрещает использовать конструктор базового контроллера? Протаскивай там свой entry point в виде IDataService и инициализируй свойство. Тебе кто-то связал руки?
а нахрена? с самого начала я задал этот вопрос. нахрена козе баян?
Я тебе ответил - для того, чтобы протащить базовый функционал в наследники. У тебя непонимание, для чего нужно наследование в ООП, или что?

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

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

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

hVosttзнал бы просто запостил генерируемый SQL, было бы больше пользы.
Зачем? Там обычный линейных выхлоп для and и or.

hVosttно ты будешь носом воротить «тебе надо, ты и проверяй». я уже понял что ресурс ты сделал для себя исключительно, а комменты только для приёма «спасибо», только вижу не больно-то они используются по назначению... в общем, не можешь вести ресурс, не берись. не пиарь его на каждом шагу.
1. Ресурс изначально был для меня, я об этом писал.
2. Не видишь назначения - это твои проблемы. Мне зачем твои изливания?
3. Я уж сам как-то определюсь, какой мне ресурс вести, а какой не вести, ок?
4. Я его не пиарю и тем более на каждом шагу, я даю пруф ссылки по теме.

Еще вопросы?

hVosttМСУ,

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

По-моему, съезжаешь ты. Третий раз спрашиваю, не уходи от темы:

МСУкак мне с помощью твоих фильтров отстроить UI в разрезе пользовательских прав?

По-моему простой вопрос - ответ будет?

hVosttты привел пример, я его перебросил на фильтры.
Я тебе задал вопрос про отруливание секьюрити в UI, как будешь это делать с помощью фильтра? Нужно админу один функционал показать, менеджеру - другой, вьюверу - третий.

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

мдааааааааааааааааа..................... умора ей богу.
Ты либо дурак, либо идиот. Выбирай.

hVosttскажи мне, друг, в какое место тут впилась твоя Security в базовом контроллере??
Я тебя 4-ый раз спрашиваю:

hVosttскажи мне, друг, в какое место тут впилась твоя Security в базовом контроллере??
Я тебя 4-ый раз спрашиваю:

МСУкак мне с помощью твоих фильтров отстроить UI в разрезе пользовательских прав?

Где ответ?

hVosttну всё, если прозвучало слово «обезьянка», значит разумные аргументы кончились ))))) ты в своём репертуаре, респект!
Ты аргументы пропускаешь мимо ушей и не отвечаешь на прямые вопросы. Так что давай не будем про репертуар.


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

hVosttтак ты покажешь SQL? или ты настолько уверен в своих словах, что проверять ничего не нужно?
Я уверен в своих словах на 100%. Тебя устраивает такой ответ?

hVosttзадето твое раздутое ЧСВ, я уже понял. остальное уже не имеет никакого значения.
Имеет - ответь на вопрос про отруливание UI в разрезе пользовательских полномочий. 5-ый раз прошу ответить.

hVosttМСУ,

если надо фильтровать данные по юзеру, это вообще не задача контроллера, а бизнес-логики.

если надо ограничить доступ к действиям, например, по ролям, есть вот такая штука [Authorize(Roles = "admin,manager")] — или пишешь свой фильтр, можешь на базе стандартного или полностью свой.

еще вопросы??

Какой в зад Authorize?! Ты точно инопланетянен...

Для тех, кто в танке - еще раз, с пережевыванием ситуации: нужно отстроить UI в разрезе полномочий HasUserProductsView, HasUserProductsEdit, HasUserProductsDelele. Причем тут Authorize?

hVosttесли надо фильтровать данные по юзеру, это вообще не задача контроллера, а бизнес-логики
1. А кто тебе сказал, что эту задачу решает контроллер? Эту задачу решает секьюрити класс - в нем вся логика в разрезе безопасности. В контроллере лишь прокинут доступ к этом механизму. Ты всегда понимаешь элементарные вопросы с 10 раза?
2. Что такое "надо фильтровать данные по юзеру"? Что за новый бред?

У тебя сложности с понимаем этого вопроса?

"как мне с помощью твоих фильтров отстроить UI в разрезе пользовательских прав?"

hVosttМСУ, тебе никто не мешает иметь свой синглетон типа WebSecurity, доступный во всем приложении.
Аааа...! А как же фильтр? А как же DI?

hVosttнет смысла его тащить в контроллер. но если так уж хочется «сахара», создай Extensions для контроллера. я не понимаю, почему мы скатились до обсуждения откуда стучаться к своему Security, ты можешь его засунуть в базу, никто тебе не мешает. но необходимости в этом нет никакой абсолютно.
1. За синглтон - сразу тебя уволить нахрен.
2. За отдельный Extensions для контроллера: вот скажи мне, ты реально дурак или прикидываешься? Security глобален для всего приложения и даже нескольких приложений, причем тут "Extensions для контроллера"? Ты не понимаешь, что несешь бред сивой кобылы?

hVosttкроме того, всем ли контроллерам нужен этот Security? чем вот такой вариант плох:
Всем. И не только контроллерам.