Ответы пользователя по тегу ASP.NET
  • C#: Как правильно организовать сервисы в Business Logic Layer с помощью DI?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    1. BarService как бизнес-сервис не должен знать о другом бизнес-сервисе, т.е. о FooService. Если приходит понимание, что в BarService нужно вызывать метод из FooService, значит Ваш FooService должен стать компонентом более низкого уровня, чем бизнес-сервис. Например, FooManager (вспомните всякие ***Manager из ASP.NET Identity). Тогда этот FooManager можно будет использовать не только в BarService, но в каком-нибудь другом ***Service. Архитектурно будет выглядеть так: наверху ***Service (бизнес-логика), ниже - ***Manager (тоже бизнес-логика), еще ниже - ***Repository (а это уже DAL).
    2. Да, бывает необходимость расширить Generic-репозиторий конкретным репозиторием. Но тут надо очень хорошо подумать, почему мы это делаем. Возможно, мы пытаемся на конкретный репозиторий навесить часть бизнес-логики? Если так, то это уже не конкретный репозиторий и даже не компонент уровня DAL - это компонент уровня бизнес-логики. Ну да ладно, допустим, мы поняли, что нам-таки нужен IFooRepository. Я сталкивался с таким решением этой задачи: в IUnitOfWork добавляется новое свойство:
    public IFooRepository FooRepository {get; }
    И все. Инициализация выполняется внутри экземпляра UnitOfWork, например, так:
    public IFooRepository FooRepository {get; } = new FooRepository();

    а "наружу" нам доступен FooRepository:
    _uow.FooRepository.CallSomeMethod(...);
    В итоге в BarService Ваш код будет выглядеть примерно так:
    public void CreateBar(BarDTO bar) 
    {
        // Insert Bar entity
        
        _uow.FooRepository.CreateFoo(new FooDTO()); 
    
        _uow.Commit();
    }


    Но повторюсь. В Вашем примере у меня есть подозрения, что метод CreateFoo должен принадлежать не FooRepository, а какому-то компоненту уровня бизнес-логики (но в иерархии он не является бизнес-сервисом). Например, FooManager или FooCreator какой-нибудь (который отвечает только за создание объекта). Помните принцип SRP.
    Ответ написан
    Комментировать
  • ASP.NET Core: чего нет в .Net Core в сравнении с .Net Framework?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день! Из собственного опыта: в .NET Core отсутствует подсистема работы с графикой (System.Drawing, кажется). Т.е. если Вы вдруг на стороне сервера решите формировать, скажем, капчу, то у Вас это не получится. Также неполная поддержка рефлексии (в частности, отсутствует класс StackFrame).
    Ответ написан
    Комментировать
  • Что не так с ASP.NET Identity в Onion архитектуре?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Правильно ли я реализовал Repository + UnitOfWork

    Ну, насколько я знаю, существует множество реализаций UnitOfWork + Repository, и каждая их них обладает своими достоинствами и недостатками. У Вас все выглядит достаточно работоспособно и юнит-тестируемо.

    Правильно ли реализовано Dispose

    В принципе, да. Только вот private fields на то и private, чтобы их инкапсулировать. Считаю очень неправильным, что у вас переменная disposed имеет модификатор public. Еще видел где-то в сети, что рекомендуют явно присваивать в переменную db значение null после вызова db.Dispose():
    if (_db != null)
    {
        _db.Dispose();
        _db = null;
    }

    Не хочу показаться навязчивым или развивать тему холивара, но именовать private field через символ "_" в начале имени, на мой взгляд, все же удобнее. Т.е. вместо private DbContext db лучше написать private DbContext _db. Как мне кажется, визуально такой код другим людям читать легче.

    В каком слое по вашему должен находится ApplicationSignInManager, ведь он использует OWIN и работает с ApplicationUserManager

    Зависит от сложности Вашего приложения. Может быть такая ситуация, что MVC-приложений несколько, но они должны использовать один механизм авторизации/аутентификации. Тогда компонент ApplicationSignInManager можно вынести в отдельный проект. Если такой необходимости нет, то, на мой взгляд, можно спокойно оставить его в клиенте (MVC-app).

    Ввиду того что о базе и орм не знает ни один слой кроме DAL я решил вынести connectionString в константу, это нормальный подход?

    Нет. Строки подключения к БД лучше всего хранить как настроечные параметры. Для ASP.NET 5 - в web.config, например. Для ASP.NET Core - например, в файле appsettings.json.

    Есть смысл вынести сущности в отдельный проект и отделить их от аннотаций для бд?

    Однозначно. Потому что Ваши сущности представляют доменную модель. Выделение их в отдельный проект позволит сделать более модульной Вашу архитектуру, а следовательно, Вы сможете подрубать этот проект только там, где он нужен, не таща с собой всякие DbContext-ы, Repository, UnitOfWork-и и др.


    В примере в owin контекст засовывают ef контекст вот таким образом app.CreatePerOwinContext(ApplicationDbContext.Create); насколько это оправдано и стоит ли так делать?
    В реализации UserStore для EF очень странно ведут себя с dispose и у меня ощущения что некоторые данные висят в памяти постоянно, так ли это?

    Вот тут не подскажу. Буду рад также услышать компетентное мнение.

    Насколько вообще оправдан такой велосипед?

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

    В свое время мне очень помогла вот эта серия статей (из 4 частей): techbrij.com/generic-repository-unit-of-work-entit...
    Ответ написан
    1 комментарий
  • Я не умею готовить репозиторий или он просто не очень?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Коллеги, добрый день!

    Почему никто не упомянул про паттерн UnitOfWork? Паттерн репозиторий становится очень удобным в использовании, если:
    1. это паттерн GenericRepository;
    2. при необходимости можно добавить конкретные репозитории (я их называю ConcreteRepository;
    3. ну и конечно же, если всем этим управляет UnitOfWork;


    При использовании такой связки у Вас:
    • если много сущностей и есть GenericRepository, то вам не нужно плодить репозиторий на каждую сущность - достаточно сделать так: var unit = UnitOfWork.Repository<UserLog>();
    • пункт выше автоматически решает проблему "как выбрать данные из 2-3-4-... таблиц" - с репозиториями вы работаете как с DbSet в EF (кстати, сам DbContext из EF, по сути, реализует паттерн UnitOfWork и GenericRepository);
    • автоматически решается вопрос расширения вашего репозитория методами на каждый чих (т.е. надо получить список логов для конкретного пользователя - добавляем новый метод GetLogsByUserId в репозиторий) - не нужно накручивать репозиторий новыми методами, достаточно сделать так: var unit = UnitOfWork.Repository<UserLog>().GetQuery(e => e.UserId == targetUserId) или var unit = UnitOfWork.Repository<UserLog>().AsQuaryableQuery(e => e.UserId == targetUserId) (методы GetQuery и AsQuaryableQuery - это методы у сущности UnitOfWork, которые возвращают IEnumerable или IQueryable соответственно);
    • если методы SaveChanges/Commit реализованы в UnitOfWork (и UnitOfWork управляет транзакциями БД), то у вас решается проблема консистентности данных - UnitOfWork либо подтверждает все изменения (Commit), либо откатывает в случае ошибок (Rollback);
    Или мне спецальный класс завести в которомом сразу будут все репозитории(как dbContext прям)?

    Правильно мыслите - этот специальный класс и есть UnitOfWork. Он "прям как dbContext", только таким образом вы абстрагируетесь от всяких EF, NHibernate и прочих ORM. В итоге вашей бизнес-логике по барабану, какую ORM вы используете.

    Если мне нужен в 1 контроллере/сервисе не 1 репозиторий? мне по 1 их подключать? может мне 15 надо.

    Достаточно подключить 1 UnitOfWork (и лучше это делать через внедрение зависимостей - DI - DependencyInjection с использованием IoC-контейнера, например, Autofac, Ninject, Unity. Autofac лично мне нравится больше хотя бы потому, что у него самая адекватная и понятная документация, чем у Ninject и уж тем более Unity [нет, это не тема для холивара "кто лучше: Autofac/Ninject/Unity/... - это всё выводы из моего личного опыта]).

    И главный вопрос. Нужно ли вообще применять этот паттерн если ты не используешь юнит тестирование, либо не используешь его для покрытия 100% всего кода а только отдельные хелперы? Ведь для перехода на другую бд достаточно будет сменить провайдер если используешь ef, и если вы используете орм врядли вы полностью от неё откажетесь. Зачем писать кучу кода "наперед" с принципом "а вот вдруг мы поменяем бд/ос", да это скорей всего уменьшит изменения кода по сравнению с полной переписыванием проекта. Но если ты уверен что ос и бд не поменяется?

    В любом enterprise-проекте надо думать наперед, даже если это проект "маленький интернет-магазинчик". Потому что через год этот маленький интернет-магазинчик может превратиться в нормальный такой бизнес с очень высокими оборотами и прибылью, и тогда, если у Вас не будет хорошей абстрагированной архитектуры, если у вас не будет модульности, то любая новая задача будет реализовываться со все большим количеством костылей, и любая новая задача будет приводить к неустойчивости системы и повышению степени регресса (проверено!). А вот если вы как архитектор вложите при разработке в вашу систему модульность и абстрагирование компонентов, то вы тем самым уже упростите себе жизнь в будущем, а это означает, что через какое-то время любая задача по изменению системы будет решаться быстрее, надежнее, а значит, вы сможете брать как разработчик за это больше денег (потому что стоимость новых изменений будет гораздо ниже). А если вы еще и юнит-тестирование будете использовать при разработке, то тем самым вы снижаете риск регресса в поведении вашей системы, что опять же, снижает стоимость разработки лично для вас. Поверьте, когда система имеет хотя бы модульность и абстрагирование компонентов друг от друга (т.е. какой-либо компонент зависит от абстракции - в виде интерфейса или абстрактного класса, а не от реализации - в виде конкретного класса), то работа с такой системой будет доставлять удовольствие.

    СУБД менять - это не такая распространенная практика, а вот от ORM (и от EF в частности) отказываться в пользу производительности - это реальный кейс с ростом нагрузки.

    Толстый Лорри - абсолютно с Вами согласен по этому поводу.

    Михаил очень в тему упомянул принцип единственной ответственности. 1 компонент - 1 ответственность. По себе заметил - если следовать хотя бы этому принципу, то уже автоматически система становится модульной. А раз есть модули, то можно снизить степень связанности компонентов между собой, используя абстракции (интерфейсы и абстрактные классы). А раз есть абстрагирование между компонентами, то юнит-тестирование будет только в радость. Причем компонентом может выступать как класс, так и целый проект. Например, в отдельный проект можно вынести какой-нибудь модуль системы, и затем этот проект можно подключить в другую систему при разработке. Таким образом повышается степень повторного использования кода (зачем 2 раза делать одно и то же?).

    Михаил еще также указал в комментарии, в каких случаях репозиторий можно не использовать. Добавлю: в не-enterprise-решениях. Например, вы делаете какой-нибудь простенький сайт для себя. Или для друга. Или просто для изучения новой технологии.
    Ответ написан
    8 комментариев
  • Трехслойная архитектура приложения, слой бизнес логики, как вынести сортировку из контроллера в отдельный метод в бизнесс логике?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день! Формируете слой бизнес-логики, слой доступа к данным. В слое бизнес-логики создаете какой-нибудь "бизнес-сервис" а-ля "ItemsService". В этом классе создаете метод с похожей сигнатурой. И всю основную логику по фильтрации переносите из метода действия контроллера в метод бизнес-сервиса. В контроллере Вы лишь обращаетесь к экземпляру бизнес-сервиса и вызываете нужный метод, который делает всю основную работу. В итоге Вы "сажаете Ваш контроллер на диету" - код в методах действия значительно сокращается, и методы действия после таких операций ничего не будут знать о бизнес-логике. По этой теме также сразу изучаете вопросы: IoC-контейнер (мы с коллегами отдаем предпочтение Autofac) и Dependency Injection.
    Ответ написан
    Комментировать
  • [DI] Resolve типа внутри метода контроллера (ASP.MVC). Как реализовать?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Существуют ли какие-нибудь готовые решения, позволяющие резолвить типы внутри метода контроллера (желательно с возможностью настройки через XML, как в Unity)?

    Добрый день!
    Если Вы пытаетесь резолвить что-то из IoC-контейнера в методе действия, значит, Вы идете по не совсем правильному пути (т.к. резолвить напрямую из контейнера приводит к значительным утечкам памяти из-за того, что GC не может их очистить, т.к. они "используются" самим IoC-контейнером). Что мешает Вам передавать Ваш ISomeRepository в конструктор контроллера и записывать его в private field?

    Я бы делал так, как предложил Free_ze в комментариях к Вашему вопросу:
    1. Пишем фабрику контроллеров (или подключаем готовую, если она есть в комплекте с IoC-контейнером)
    2. Вставляем интерфейсы в конструкторы контроллеров


    Контроллер будет выглядеть в этом случае так:
    private readonly ISomeRepository _someRepo;
    public MyController(ISomeRepository someRepo)
    {
        if(someRepo == null)
            throw new ArgumentNullException(nameof(someRepo));
        _someRepo = someRepo;
    }


    Дальше используем _someRepo как душе будет угодно. Такой подход более правильный с точки зрения разрешения зависимостей. Про IoC-контейнер, по сути, должен знать только тот, кто его конфигурирует.

    P.S. Бонус: если у Вас много репозиториев и интерфейсов для них, значит, настала пора рефакторинга. Смотрите в сторону GenericRepository + UnitOfWork.
    Ответ написан
    Комментировать
  • Где должна находиться Domain Model?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день! DomainModel можно располагать и в отдельном слое (это уже шаг в сторону "луковичной" архитектуры (onion). Например, если доменная модель сильно совпадает с моделями в DAL, то имеет смысл расположить ее в отдельном проекте VS, навесить атрибуты Column, Key, ForeignKey, NotMapped (и др. атрибуты из DataAnnotations) - это в случае, если у Вас EF CodeFirst (с EF Database first такое особо не прокатит - только через partial-классы, но, на мой взгляд, это "уродство"), после чего в слое DAL останется только функционал подключения к БД и выполнения запросов. Если доменная модель сильно различается от модели DAL, то можно написать всякие обертки, которые будут преобразовывать классы доменной модели в модели DAL и наоборот.

    Я бы советовал доменную модель выносить в отдельный проект. Почему? Потому что так ею проще пользоваться. Иначе Ваш бизнес- или DAL-слой превратится со временем в помойку: там будут и атрибуты, и исключения, да еще в каждом слое свои, и enum, и всякие сервисы/менеджеры/хелперы/... При разбиении решения на проекты, на мой взгляд, также следует придерживаться принципа единственной ответственности (S из SOLID). Каждый проект отвечает за что-то одно. Это позволяет спокойно подключать/отключать функциональности из других проектов (получается что-то вроде модульности решения) и избавляет от циклических зависимостей между проектами (когда у Вас есть проект MyApp.Common, который подключен в MyApp.BLL, но в слое MyApp.BLL есть функционал, который нужно использовать внутри проекта MyApp.Common => получается циклическая зависимость, и способ ее решения - перенести общий функционал в отдельный проект).
    Ответ написан
    Комментировать
  • Как реализовать Asp.Net Identity 2.0 авторизацию на Onion-архитектуре?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Я пока что обнаружил рабочий вариант, который очень хорошо тестируется.

    1. Создаем несколько проектов:
    - DAL.Abstract - лежат интерфейсы Generic-репозитория, специализированных репозиториев и UnitOfWork'а;
    - DAL.Real - содержит реализации интерфейсов из DAL.Abstract;
    - DAL.Fakes - fake-реализации для юнит-тестов;
    - BL.Abstract - лежат интерфейсы бизнес-сервисов;
    - BL.Real - здесь реализации интерфейсов бизнес-сервисов;
    - BL.Fakes - fake-реализации вспомогательных сервисов (EmailService, SmsService из Identity);
    - BL.Tests - юнит-тесты бизнес-логики;
    - Core.Models - модели предметной области (code-first).

    2. Т.к. я использую шаблон UnitOfWork, то пришлось отказаться от готовой реализации из библиотеки Identity.EntityFramework в силу того, что в ней расположены уже готовые классы User, Role, Claims и др., и приходится эту библиотеку тащить во все проекты, где нужно использовать хотя бы User'а. А вслед за ней во все проекты тащится библиотека EntityFramework... Мне это не нравится, потому что, на мой взгляд, слой MVC не должен знать про частности реализации (т.е. про EntityFramework).
    Поэтому самый простой вариант - сделать велоси... гм, собственную реализацию всяких там IUserStore, IPasswordStore и др.интерфейсов из Microsoft.AspNet.Identity.Core (ну и соответственно, создать собственные классы User, Role, UserRole, Claims, ExternalLogin), которые могли бы работать с нужным мне UnitOfWork'ом.

    3. Пишем тест:
    [TestFixture]
        public class UserServiceTests
        {
            private FakeEmailService _emaiService;
            private FakeSmsService _smsService;
            private IUserServiceFactory _userServiceFactory;
            private IUserService _userSrv;
            private IAuthenticationManager _authManager;
            private IUserRepository _userRepository;
    
            [SetUp]
            public void PreInit()
            {
                var authManagerMock = new Mock<IAuthenticationManager>();
                _authManager = authManagerMock.Object;
    
                _userRepository = new FakeUserRepository();
    
                _smsService = new FakeSmsService();
                _emaiService = new FakeEmailService();
                _userServiceFactory = new UserServiceFactory(
                    new FakeUnitOfWorkFactory(_userRepository),
                    _emaiService, _smsService, _authManager);
    
                _userSrv = _userServiceFactory.Create();
                // Заполняем хранилище пользователем "exist@exist.ru"
                RegisterExistUser();
            }
            private RegisterResult RegisterExistUser()
            {
                var model = new RegisterNewUserViewModel(ConstForTest.Users.ExistUser.Email, ConstForTest.Users.ExistUser.Password);
                return RegisterUser(model);
            }
            // Регистрация пользователя "valid@user.ru"
            private RegisterResult RegisterValidUser()
            {
                var model = new RegisterNewUserViewModel(ConstForTest.Users.ValidUser.Email, ConstForTest.Users.ValidUser.Password);
                return RegisterUser(model);
            }
    
            [Category(ConstForTest.Categories.UserServiceTests.RegisterNewUser)]
            [Test]
            public void RegisterNewUser_ValidEmailAndPassword_AfterRegistrationEmailDoesNotConfirmed()
            {
                var email = ConstForTest.Users.ValidUser.Email;
    
                // Act
                RegisterValidUser();
    
                var foundUser = _userSrv.GetUser(email);
                Assert.IsNotNull(foundUser);
                Assert.IsFalse(foundUser.EmailConfirmed);
            }
        }


    4. Пишем логику бизнес-сервисов. Приведу пример регистрации юзера:
    public class UserService : IUserService
        {
            private readonly IUnitOfWorkFactory _unitFactory;
            private readonly IUserIdentityManagerFactory _userManagerFactory;
            private readonly ISignInManagerFactory _signInManagerFactory;
    
            public UserService(IUnitOfWorkFactory unitFactory, 
                IUserIdentityManagerFactory userManagerFactory,
                ISignInManagerFactory signInManagerFactory)
            {
                _unitFactory = unitFactory;
                _userManagerFactory = userManagerFactory;
                _signInManagerFactory = signInManagerFactory;
            }
    
            public RegisterResult RegisterNewUser(RegisterNewUserViewModel model)
            {
                using (var unit = _unitFactory.Create())
                {
                    RegisterResult result = new RegisterResult();
                    IdentityResult identityResult;
                    try
                    {
                            var username = model.Email;
                            var manager = CreateUserManager(unit.UserRepository);
                            identityResult = manager.Create(new User(username), model.Password);
                            if (identityResult.Succeeded)
                            {
                                var createdUser = unit.UserRepository.GetByUsernameQuery(username);
                                manager.AddToRole(createdUser.Id, Roles.Client.ToString());
    
                                var confirmEmailCode = manager.GenerateEmailConfirmationToken(createdUser.Id);
                                result.ConfirmEmailCode = confirmEmailCode;
                                manager.SendEmail(createdUser.Id, Const.EmailSubjects.Account.ConfirmEmail,
                                    "<Тут содержимое  письма для подтверждения е-майл пользователя>");
                            }
                            unit.Commit();
                    }
                    catch (Exception ex)
                    {
                        identityResult = IdentityResult.Failed("В процессе регистрации возникла ошибка. Попробуйте выполнить операцию еще раз.");
                        unit.Rollback();
                    }
                    result.IdentityResult = identityResult;
                    return result;
                }
            }
            
            // ... другие методы бизнес-сервиса
            
        }


    Метод CreateUserManager(unit.UserRepository) создает экземпляр класса UserManager из библиотеки Microsoft.AspNet.Identity), передавая ему репозиторий работы с пользователями (да-да, т.к. у нас Identity, то необходимо вынести репозиторий для юзеров в отдельный интерфейс IUserRepository):
    private UserManager<User, Guid> CreateUserManager(IUserRepository userRepository)
            {
                return _userManagerFactory.Create(userRepository);
            }


    Фабрика создания UnitOfWork'а выглядит так:
    public interface IUnitOfWorkFactory
        {
            IUnitOfWork Create();
            IUnitOfWork Create(IsolationLevel level);
        }    
        public class EfUnitOfWorkFactory : IUnitOfWorkFactory
        {
            public IUnitOfWork Create()
            {
                return Create(IsolationLevel.ReadCommitted);
            }
    
            public IUnitOfWork Create(IsolationLevel level)
            {
                var uow = new EfUnitOfWork(level);
                return uow;
            }
        }

    Сам UnitOfWork:
    public interface IUnitOfWork : IDisposable, IUnitOfWorkRepositories
        {
            void SaveChanges();
            void Commit();
            void Rollback();
        }
        public interface IUnitOfWorkRepositories
        {
            IUserRepository UserRepository { get; }
        }
        public class EfUnitOfWork : IUnitOfWork
        {
            private bool _isDisposed = false;
            private DbContext _db;
            private DbContextTransaction _transaction;
    
            public EfUnitOfWork(IsolationLevel level = IsolationLevel.ReadCommitted)
            {
                _db = new MyApplicationDbContext();
                _transaction = _db.Database.BeginTransaction(level);
            }
    
            #region IDisposable
    
            protected virtual void Dispose(bool disposing)
            {
                if (!_isDisposed)
                {
                    if (disposing)
                    {
                        if (_transaction != null)
                        {
                            _transaction.Rollback();
                            _transaction.Dispose();
                            _transaction = null;
                        }
                        _db.Dispose();
                        _db = null;
                    }
                }
                _isDisposed = true;
            }
    
            public void Dispose()
            {
                Dispose(true);
                GC.SuppressFinalize(this);
            }
    
            #endregion
    
            #region IUnitOfWork
    
            public void SaveChanges()
            {
                _db.SaveChanges();
            }
    
            public void Commit()
            {
                SaveChanges();
                _transaction.Commit();
            }
    
            public void Rollback()
            {
                _transaction.Rollback();
            }
    
            #endregion
    
            private IUserRepository _userRepo;
    
            public IUserRepository UserRepository
            {
                get { return _userRepo ?? (_userRepo = new EfUserRepository(_db)); }
            }
        }


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

    P.S.
    1. Буду рад замечаниям со стороны опытных коллег относительно данной реализации.
    2. В качестве основы взяты материалы цикла статей
    3. Я придерживаюсь той концепции, что ни один Repository не должен знать про SaveChanges, а уж тем более про Commit и Rollback. Это прерогатива UnitOfWork'а, а Repository должен реализовывать лишь CRUD-операции. Поэтому метод SaveChanges вынесен в интерфейс IUnitOfWork.
    Ответ написан
    Комментировать
  • Как легче освоить внедрение зависимостей, code-first, TDD и паттерны?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый вечер! Спасибо за приглашение.
    На мой взгляд, Вам следует придерживаться следующих приоритетов по изучению:
    1. внедрение зависимостей более важно из Вашего списка, т.к. относится к SOLID принципам;
    2. TDD - на мой взгляд, вещь более нужная для изучения, чем code-first или patterns. Сам не так давно начал разрабатывать по TDD. Это очень здорово, что изобрели такой подход. Экономит тонну времени на ручное тестирование, а также дает быстрое понимание, что и где случайно (или неслучайно) сломалось. Главное - понимать, что покрывать тестами;
    3. третьим в список я бы добавил AngularJS или KnockoutJS или BackboneJS - сам пока что не изучил их и не начал применять, но судя по их популярности и преимуществам - думаю, Вам стоит с ними ознакомиться;
    4. code-first или database-first - не так уж и важно на Вашем этапе понимания. Главное отличие подхода Code-first: 1) модель пишется вручную, в связи с чем не нужно постоянно отслеживать edmx-диаграмму (т.е. можно считать, что Ваша code-first модель всегда находится в актуальном состоянии); 2) поддерживает миграции БД. В Database-first Вам нужно самому отслеживать актуальность состояния Вашей edmx-модели - с этим тоже могут быть проблемы. Опять же - только с опытом. С другой стороны, Database-first позволяет наглядно видеть Вашу модель, а вот Code-first - нет;
    5. паттернами тоже можете пока что голову не забивать. Безусловно, это нужно, но понимание их придет только с опытом (признаюсь честно: я сам не до конца все паттерны знаю и понимаю). На мой взгляд, важно соблюдать 1 основной паттерн - 3-уровневая архитектура (клиентский слой, слой бизнес-логики, слой работы с данными).

    Теперь по MVC.
    1. Model - тут, в принципе, всё просто: модель данных. Здесь можно поспорить, что иметь в виду под Моделью: модель самих данных или модель представления. Лично я после опыта работы с шаблоном MVVM в WPF под моделью данных в терминах ASP.NET MVC понимаю модель представления, а под термином "модель данных" - саму доменную модель (EF code-first, например). Кто-то может сказать, что это "лишняя работа" - по упаковыванию модели данных из EF-объектов в объекты модели представления. Да, частично соглашусь. Но зато это дает некую гарантию безопасности, что случайно пользователь не поменяет важную часть модели данных (например, ID).
    2. Контроллер. Основная задача контроллера - сформировать данные для отображения и передать эти данные в представление. Т.е. нужно стремиться к тому, чтобы код метода действия в контроллере содержал минимум кода. В идеале - вызов метода из слоя бизнес-логики и передача полученных данных в представление. Если Вы видите, что метод действия в контроллере содержит какую-то бизнес-логику, то это сигнал к рефакторингу: Ваш метод действия слишком много знает. По опыту могу добавить, что в среднем код метода действия содержит от 2 до 20-30 строк кода (с учетом того, что скобки { и } расположены на отдельных строках).
    3. Представление. Тут тоже всё просто: отобразить данные (из модели представления). Ни в коем случае нельзя в представлении писать логику по работе с самими данными, например, так делать нельзя:
    <div id="account">
        @{
            using(var db = new MyEfDbContext()
            {
                var userAccount = db.Accounts.FirstOrDefault(e => e.Username == User.Identity.Username);
                if(userAccount != null)
                {
                    @:Имя: @userAccount.Name
                    @:Фамилия: @userAccount.LastName
                }
            }
        }
    </div>


    Если у Вас 3-уровневая архитектура, например, есть слои:
    1. MyApp.MVC - MVC-application
    2. MyApp.BL - слой бизнес-логики
    3. MyApp.DAL - слой работы с данными
    то в представлении (View) вызывать напрямую сервисы бизнес-логики тоже нельзя, особенно, если Вы используете DI-принцип (внедрение зависимостей) и IoC контейнер. Т.е. такой пример недопустим:
    <div id="account">
        @{
            var accountService = new MyApp.BL.AccountService();
            var userAccount = accountService.GetUserAccountByUsername(User.Identity.Name);
            if(userAccount != null)
            {
                @:Имя: @userAccount.Name
                @:Фамилия: @userAccount.LastName
            }
        }
    </div>

    Попробую донести мысль архитектора и разработчика Александра Шевчука (преподавателя с http://itvdn.com): "Одна из главных целей при разработке - стремиться к упрощению системы". Ослабление зависимостей позволяет нам упрощать систему благодаря тому, что изменение осуществляется только на 1 каком-то слое/уровне. Если Вы во View вынесете логику по работе с данными, а уж тем более, как в примерах выше, работу с EF-контекстом, то Вы усилите зависимость одного компонента системы (MVC-слоя) от другого (слоя работы с данными или слоя бизнес-логики). Усиление зависимостей приводит к бОльшему числу изменений, что в свою очередь сказывается на повышении расходов на эту систему. Ослабление зависимостей приводит к меньшему числу изменений (например, при переходе от EF к native SQL или NHibernate затрагивается только слой работы с данными, а слой MVC и бизнес-логики не меняются), а значит, к более раннему выпуску системы или очередного релиза, и как следствие, снижение расходов (не только денежных, но и других ресурсов) на разработку. TDD тоже можно отнести к практикам, которые снижают затраты ресурсов на содержание системы. Но это я ушел в глобальное...

    Правильным будет подход, при котором у Вас снижается зависимость компонентов системы друг от друга, в случае с ASP.NET MVC приложением, на мой взгляд, это когда:
    - View знает о модели (я по прежнему буду иметь в виду модель представления - ViewModel, которые объявлены либо в MVC-слое, либо в слое бизнес-логики);
    - контроллер знает о слое бизнес-логики, обращается к нему за выполнением операций и получением ViewModel'ей, после чего передает во View полученную ViewModel (ну или JSON-данные);
    - Model формируется по принципу, грубо говоря, почти на каждую View своя модель.

    Фразу "правильным будет подход" я обосновываю тем, что у такого подхода есть масса плюсов (которые очевидны опытным разработчикам, но могут быть не до конца или неправильно поняты менее опытными коллегами, а именно):
    + View ничего не знает о доменной модели (только о ViewModel), благодаря чему Вы можете спокойно менять свою доменную модель, не внося изменений во View (см. выше про ослабление зависимостей и снижение количества связей). Также Вы спокойно можете перейти от EF к NHibernate или к native SQL, или использовать и то, и другое - View об этом никогда не узнает;
    + контроллер (да и весь MVC-слой) знает только о существовании слоя бизнес-логики, но ничего не знает о слое работы с данными.
    + если на View делать отдельную ViewModel, то это позволяет более полноценно управлять тем, что нужно показать пользователю. Т.е. дает возможность большего контроля отображаемых данных, повышает безопасность Вашего приложения (пользователь, например, не сможет изменить ID просматриваемой записи, если этого ID нет вообще в модели представления).

    Ну а вообще все зависит от задачи/проекта: нужно ли применять разбивку на слои или использовать ViewModel'и вместо обычных доменных моделей - надо думать над каждой ситуацией отдельно.

    P.S. На мой взгляд, литературу выбрали правильно - я тоже начинал изучение MVC с нее. Понравилась тем, что дается сначала общее описание и работа с ASP.NET MVC на сквозном примере. А потом идет более глубокое погружение в ASP.NET MVC. По разработке могу посоветовать блог Александра Бындю: blog.byndyu.ru Как мне кажется, там очень хорошо некоторые моменты разжевываются, в том числе SOLID, TDD, шаблон Repository, UnitOfWork и др.
    Ответ написан
    2 комментария
  • Как указать ссылку в зависимости от роли?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Можно использовать атрибут Authorize - его можно "навесить" либо целиком на контроллер, либо на метод действия - читайте литературу по MVC.

    Как узнать роль пользователя?

    Вопрос странный: пишете метод IsUserInRole или как-то так и реализуете, как надо (в MembershipAPI, например, реализация уже есть). В MVC в любой момент времени доступен объект User.Identity, у которого можно вытащить свойство Username. По username можно определить его роль - проблемы особой не вижу. Можно написать еще свою "обертку" над объектом пользователя, ему в свойства "засунуть" роли или добавить кучу свойств вида Is, например: IsAdmin, IsGuest, затем к этим свойствам обращаться - тут уже как у Вас фантазия заработает.
    Ответ написан
    Комментировать
  • Как защитить ASP.NET MVC приложение от администратора?

    Valeriy1991
    @Valeriy1991 Автор вопроса
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Коллеги, в принципе, можно отнести это к решению вопроса - в Visual Studio при публикации ASP.NET приложения в настройках Publish'а есть такая опция - "Precompile during publish". При конфигурировании этой опции снимается галочка с "Allow precompiled site to be updatable" + можно поиграться с блоком "Merge option". Эта галочка способствует тому, что все View при публикации будут преобразованы в *.dll файлы, а блок "Merge option", насколько я понял, позволяет настроить различные способы этого преобразования View -> dll. Решение пока отмечать не буду - хотелось бы услышать еще варианты и "поиграться" с этими настройками публикации.
    Ответ написан
    Комментировать
  • Правильное использование UnitOfWork в сервисах?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    По первому вопросу я бы отдал предпочтение using, потому как можно случайно забыть явно вызвать Dispose. А using, как известно, вызовет его сам.

    А вот по второму вопросу - боюсь, не смогу подсказать единственно верного решения. Я сам как-то столкнулся с такой проблемой, и долго думал, как ее решить. Особенно когда идет использование IoC-контейнеров. На одном из проектов компании, где сейчас работаю, используется такой подход: создается синглтон, у которого в качестве свойств перечислены интерфейсы, например:

    public sealed class Endpoint
        {
            ...
            // Закрытый конструктор
            private Endpoint()
            {
                Initialization();
            }
            ...
            
            // Реализация синглтона
            public static Endpoint Instance
            {
                get
                {
                    if (_instance == null)
                    {
                        lock (InstanceLocker)
                        {
                            if (_instance == null)
                                _instance = new Endpoint();
                        }
                    }
    
                    return _instance;
                }
            }
            ...
            public IMyService MyService { get; private set; }
            public ISomeService SomeService { get; private set; }
            ...


    И затем эта некая общая "точка доступа" используется следующим образом:

    var serviceResult = Endpoint.Instance.MyService.GetData();

    Т.к. это синглтон, то обращение Endpoint.Instance всегда создаст единственную реализацию вместе со всеми необходимыми сервисами.
    Из плюсов - доступ из любого места (в рамках разумного, конечно же) к любому сервису.
    Ответ написан
  • Что возвращать, Empty collection или null?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Правильным будет следующий вариант:

    public IEnumerable<Adresses> GetAdresses()
            {
                try
                {
                     return dbContext.Adresses.ToList();
                }
                catch (Exception ex)
                {
                    // Логируем ошибку - что-то вроде:
                    //_loggerService.Error(ex);
                    throw;
                }
            }


    А снаружи, например, у Вас будет метод, который при ловле исключения будет выдавать что-то осознанное пользователю:
    public ActionResult Addresses()
            {
                try
                {
                     var addressList = _dataService.GetAdresses();
                     return View("_Addresses", addressList);
                }
                catch (Exception ex)
                {
                    TempData["Error"] = "Не удалось загрузить список адресов. Попробуйте позже."
                     return View("_Addresses");
                }
            }


    Во View я бы тоже советовал всегда делать проверку на null, потому что по независящим от Вас причинам Model спокойно может быть null. И лучше на клиенте такие ситуации обрабатывать, чтобы у Ваших пользователей не было ступора и они не перестали пользоваться Вашим веб-приложением.
    <div>
    @if(Model != null && Model.Any())
    {
       <div>
           @foreach(var address in Model)
           {
               @*Здесь вывод Ваших адресов*@
           }
       </div>
    }
    else
    {
        <div>
            @TempData["Error"]
        </div>
    }
    </div>
    Ответ написан
    Комментировать
  • ASP.NET MVC DDD: зачем повторять один и тот же код 3 раза?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Верным является такой подход, который решает поставленную задачу эффективно, быстро и просто. Моя деятельность связана с проектами по автоматизации бизнес-процессов заказчиков. В таких проектах лучше делить всю логику на несколько слоев: слой представлений (в частности, приложение на ASP.NET MVC, WPF, WinForms), слой бизнес-логики (отдельная библиотека, class library), слой доступа к данным (тоже отдельная библиотека).

    Опишу пример.
    В одном из своих личных проектов на ASP.NET используется как раз разделение логики на слои. Есть несколько проектов: MyApp.MVC, MyApp.DAL, MyApp.BL. Соответственно, общая схема работы такая: в контроллерах слоя MyApp.MVC идет обращение к методам из слоя MyApp.BL (слой бизнес-логики). Если методу из слоя MyApp.BL нужно поработать с данными БД, то он уже обращается к методам слоя работы с данными (MyApp.DAL). Слой MyApp.DAL уже непосредственно вытаскивает/добавляет/изменяет/удаляет данные. При этом слои не знают о конкретных реализациях методов, т.к. все базируется на интерфейсах и инверсии зависимостей (DI и IoC-контейнере, в частности - Ninject). В итоге что мы получаем:
    1. Разделение ответственности (каждый делает только то, что ему нужно, т.е. каждый выполняет свою задачу).
    2. Легкость сопровождения (нужно изменить логику выборки данных - например, изменить SQL-запрос. Все изменения коснутся только слоя MyApp.DAL, другие слои в этом случае менять не нужно и им будет "по барабану", что происходит внутри слоя MyApp.DAL).
    3. Расширяемость компонентов (здесь я имею в виду, что можно взять слой MyApp.DAL и включить его в другое приложение).
    4. Наглядность (код более чистый и последовательный).

    Я уверен, что это не "панацея", и в других типах проектах (например, игры? сложные математические модели?) такая архитектура может принести больше вреда, чем пользы (как пример, "продирание" через интерфейсы).
    Ответ написан
    Комментировать
  • Repository или CQRS?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Честно говоря, не знаю, что именно Вам понравилось в CQRS и EventSourcing. На мой взгляд, это слишком сложный, непривычный подход, который может использоваться в исключительно редких случаях (как сказал Тимур Шемсединов, все зависит от задачи). Подходы к проектированию приложения нужно применять не тогда, когда они нравятся, а тогда, когда нужно решить конкретную проблему. Если при разработке приложений всегда делать "всякие такие интересные штуки", то процесс разработки уйдет в бесконечность... Проектируйте по принципу: есть задача - как лучше (под "лучше" я понимаю: просто, эффективно, быстро) ее решить. Всё. Если проект "исключительно" в целях обучения - то пожалуйста, здесь Вы вольны использовать всё, что душе угодно. Но если проект реальный, и он Вас "кормит", то тут следует сдерживать свое рвение к новым подходам и всегда задавать вопрос: эта технология/паттерн/механизм/подход поможет решить мне эту задачу? Да - значит, берем, учим, используем, внедряем. Нет - значит, нафиг. Потом больше геморроя будет с сопровождением и изменением кода (и думайте всегда о том разработчике, которому достанется Ваш код после Вас).
    Ответ написан
    Комментировать
  • Переход. From ASP.NET To ASP.NET MVC?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!
    По собственному опыту могу сказать, что ASP.NET MVC показался мне более понятным, простым, ясным и прозрачным, чем "эти ужасные" (уж извините за субъективное мнение) ASP.NET WebForms. Начал свое знакомство с ASP.NET именно с WebForms, потом перешел на MVC - моему счастью не было предела.

    По Вашим "стадиям":
    1. Когда изучите ASP.NET MVC по книге "ASP.NET MVC x для профессионалов" (x - номер версии).
    2. Здесь все очень субъективно и зависит от самих проектов и их задач. Можно написать 15 проектов на MVC, но они все будут как один. А можно написать 2 проекта на MVC, но при этом они могут различаться настолько, что имея за плечами всего пару проектов, Вы уже будете знать наизусть весь MVC, C#, Entity Framework, JavaScript и паттерны проектирования в придачу.

    Можно, конечно, всю жизнь лепить проекты на WebForms, но я бы Вам настоятельно рекомендовал все новые проекты делать уже исключительно на MVC. Тем более что за неделю Вы сможете его спокойно изучить по книге (при условии полного рабочего дня).
    Ответ написан
    4 комментария
  • Какая должна быть структура SQL запросов, учитывая текущего пользователя?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день! Возможно, имеет смысл взять MembershipAPI из коробки и особо не париться с моделью пользователей? А мыслите, в принципе, в правильном направлении. Поддержу Станислав Макаров - если вы делаете update и delete по id записи, то и переписывать все эти запросы не надо. Возможно, использование ORM Вам упростит жизнь.
    Ответ написан
    1 комментарий
  • Реализация frontend'а для ASP.NET MVC?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Учитывая объем задач и наверняка не очень большие сроки их реализации, возможно, имеет смысл отдать front-end профессионалу. Но если таковой возможности нет, то я отдал бы предпочтение обычному Razor.

    Постараюсь объяснить - почему.

    1. AngularJS (и ему подобные) мне, увы, не знаком. Следовательно, нужно потратить достаточно много времени на его изучение и решение проблем в ходе использования в проекте. А это в свою очередь может сильно сказаться на сроках проекта.
    2. Использовать какие-либо готовые контролы (аля гриды jQueryUI и т.п.) - тут я бы не стал торопиться. Как ни крути, настает такой момент, когда нужно, чтобы эти контролы могли делать то, что от них хотят, но то, для чего они не приспособлены. Как следствие - код обрастает дикими костылями. К тому же, на мой взгляд, внешний вид оставляет желать лучшего... Если наступает понимание, что этот контрол сможет решить задачу - то тогда его можно применить.
    3. Взял бы в качестве основы front-end'а какой-нибудь нормальный frontend-framework (Bootstrap, FlatUI, Pure). Возможно - даже несколько (сам отдаю предпочтение Pure Grid + FlatUI). Проблем со стилизацией будет гораздо меньше, чем если всё самому с нуля писать.
    4. Razor вполне прост, если его правильно применять (имею в виду правильное разделение на Layout, Partial View, View, при необходимости кеширование вывода) - непонимаю, чем он Вас так пугает.
    5. Насчет всяких всплывающих окон, деревьев, гридов - отдал бы предпочтение специальным плагинам (отдельный плагин под окна, отдельный - под деревья, отдельный - под гриды). Как правило, можно найти очень удобные, простые и кастомизируемые решения. На мой взгляд, лучше использовать какие-то специализированные инструменты (которые решают только 1 задачу), чем унифицированные (которые могут решать целую кучу задач).

    Было бы здорово, если бы другие специалисты привели свою точку зрения. Интересно узнать, как люди решают подобные задачи...
    Ответ написан
    6 комментариев
  • Как правильно созвать контекст EF в конроллере asp.net?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Всем добрый день!

    Правильно - создавать трехслойную архитектуру

    Открывать контекст EF в методе действия контроллера - плохая практика. Плохая потому что:
    1. это не соответствует трехуровневой архитектуре, а следовательно, значительно усложняет внесение изменений, масштабирование и сопровождение приложения;
    2. это сразу показывает низкий уровень понимания шаблона MVC - могут даже на работу не взять;
    3. EF - это модель. А контроллер по сути своей должен лишь получить данные (модель) и передать их в представление. То, каким образом формируются данные (EF, NHibernate, XML, Files, ...) - контроллер не должно волновать. Он лишь организовывает данные, чтобы передать их в представление. Часто модель разделяют на непосредственно модель и модель представления (аналог шаблона MVVM). Контроллер получает данные (модель), из них формирует модель представления и её передает в само представление. Зачем это надо - уже другой вопрос.

    Далее - позволю себе не согласиться с инициализацией контекста EF на весь контроллер - можно, конечно, но это, опять-таки, плохая практика, потому что:
    1. возникнут проблемы с использованием многопоточности и параллельных вычислений при работе с контекстом (библиотека TPL);
    2. возникнет проблема "устаревания" данных - т.к. контекст создан на контроллер, то придется постоянно его обновлять;
    3. это, опять же, показывает уровень и опыт разработчика, а следовательно, снижаются шансы при трудоустройстве (туда, где я сейчас работаю - точно не взяли бы программистов, которые практикуют формирование модели в контроллере или которые инициализируют контекст в контроллере или при запросе).

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

    Читайте книгу "ASP.NET MVC 3/4/... Framework с примерами на C# для профессионалов" Адама Фримена и Стивена Сандерсона - там, можно сказать, приведены best practices по разработке в ASP.NET MVC с использованием EF.

    А вообще - всё зависит от задачи/проекта. Если это какой-нибудь учебный проект или ооооочень простое приложение - то можно для упрощения контекст инициализировать и в методе действия (контекст на метод действия), и при запросе (контекст на контроллер). Однако если Вы хотите повышать свой профессиональный уровень и заниматься enterprise-приложениями, то опытным путем Вы выясните, что самый лучший способ - это инициализация контекста на конкретную задачу.

    Удачи!

    P.S. Ничего плохого не имею против хабра (сам частенько читаю), но хабр - это не учебник, а источник разрозненной, но полезной информации. А Вам сейчас, судя по всему, нужна теория Структурированная теория. Найдите время и изучите "мат.часть". Поверьте, большинство вопросов по разработке на ASP.NET MVC у Вас просто отпадет.
    Ответ написан
    Комментировать
  • Как сформировать из доменной модели модель представления в ASP.NET MVC?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Михаил снова здравствуйте! В-общем, меньше слов - больше кода. Toster_q187249.zip - здесь архив с приложением. Предметную область смоделировал так, как понял :)

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

    Далее: прочтите от корки до корки книжку "ASP.NET MVC 3/4 Framework с примерами на C# для профессионалов", авторы: Адам Фримен, Стивен Сандерсон. Для MVC - на мой взгляд, это книга №1 для изучения ASP.NET MVC. Там есть всё, что нужно, и даже больше. У Вас, правда, могут возникнуть трудности с Entity Framework, потому что там они не так подробно объясняют, как с ним работать, (авторы, наверное, рассчитывают на небольшой опыт работы читателей с этим фреймворком). После чтения у Вас в голове всё встанет на свои места.

    Будут какие-то вопросы по проекту - пишите. Он, конечно, примитивный, но в целях обучения, на мой взгляд, подойдет.

    Вы, наверное, уже знаете, но, тем не менее, напишу: в контроллере должно быть минимум бизнес логики. Контроллер должен лишь получать откуда-то данные, формировать из них модель представления и отдавать модель представления в само представление. Всю логику работы с данными следует выносить в отдельный слой (например, в отдельную dll). Всю бизнес-логику, по хорошему, тоже следует выносить в отдельный слой. В итоге контроллеры MVC-приложения должны "ломиться" в слой бизнес-логики, который в свою очередь, ломится в слой работы с данными, вытаскивает их, обрабатывает и отдает "наверх" в клиентское приложение (MVC-application). Это позволяет формировать трехуровневую ахитектуру решений и тем самым создавать более масштабируемые и гибкие приложения.

    Например, то приложение, которое я Вам прислал, состоит их 2 слоев:
    1) MVC-app;
    2) Core.DAL - слой работы с данными.
    В идеале следовало бы добавить новый слой (например, Core.BL или Core.BAL) - слой бизнес-логики.
    Вот на всякий случай: Как организовать архитектуру приложений «Система управления проектами»?

    Успехов в нашем нелегком деле!
    Ответ написан