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