МСУ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.
См. выше, ты можешь управлять экземпляром в единой песочнице и подсовывать ее в базовый конструктор, фильтры и иже с ним.
единая песочница где находится? это синглетон? статик класс? отдельный менеджер? что бы вы не назвали, оно тоже должно где-то находиться )) только вот, что это за мифическая штуковина, которая снабжает инстантами контроллеры, фильтры и следит за временем их жизни?
