Где хранить методы, относящиеся к модели

Question

Надеюсь, на это уже не ответил, но я даже не знаю, что искать.

У меня есть проект MVC, и мне нужно вернуть список пользователей из БД. Достаточно просто. Но я хочу только вернуть некоторых пользователей. Опять же, простые вещи.

Что меня смущает, так это то, что я не знаю, куда я должен поместить код для этого. Если я поставлю его в контроллер, я получаю тот же код в нескольких методах и распределяюсь по нескольким контроллерам.

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

Я рассмотрел использование классов репозитория, но это просто добавляет дополнительный слой. Я использую EF6 и не выполняю никакого модульного тестирования (пока)

Код ниже показывает структуру моего класса dbcontext (я отредактировал фактический код, чтобы он был кратким).

public class LeadsDB :DbContext 
{ 
    public LeadsDB() 
     : base("Leads") 
    { 
    } 

    public DbSet<User> Users { get; set; } 

    public IEnumerable<SelectListItem> GetUserList(bool includeBlank = true) 
    { 
     return UserList; 
    } 
} 

Answer 1

Как говорится:

Все проблемы в информатике может быть решена другой уровень косвенности ... для проблемы слишком большого количества слоев косвенностью исключением.

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

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

В приложении, над которым я работаю, мы взаимодействуем только с Entity Framework для операций, связанных с данными. Все наши репозитории возвращают DTO, которые являются абстракциями нашей модели данных. Наши контроллеры также преобразуют большинство наших DTO в ViewModels, прежде чем передавать их в представления. И между диспетчерами и репозиториями есть уровень «Менеджер» для обработки бизнес-логики и проверки безопасности. В итоге у нас много слоев, но мы нашли ценность в развязывании моделей представления, презентации, бизнеса, безопасности и данных.

Answer 2

Это выглядит как Entity Framework DBContext; если это так, то используйте это как свой уровень данных.

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

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

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