Это плохая практика использования моделей классов в контроллере в MVC? - PullRequest
Новая
       10

Это плохая практика использования моделей классов в контроллере в MVC?

6 голосов
/ 13 октября 2010

Я хотел сравнить с лучшими практиками при работе с ORM или таблицами базы данных в asp.net mvc. Один из основных вопросов, которые у меня возникли, заключается в том, должен ли я создать классы модели непосредственно в контроллере. Не запрашивать базу данных, а просто использовать класс модели для хранения значений.

Например, Если я использую сущностный каркас в качестве модели ... тогда будет плохой практикой использовать объекты класса сущностей в контроллере . Есть моменты, когда просто проще напрямую использовать классы базы данных, сгенерированные в контроллере, вместо создания ViewModels или даже ViewData. У нас есть уровень доступа к данным и бизнес-уровень, где применяются все запросы и бизнес-логика, но, хотя мне и не нравится идея доступа к модели в контроллере, но действительно ли это плохая практика ?

Ответы [ 4 ]

4 голосов
/ 13 октября 2010

Да, это плохая практика из-за проблемы "чрезмерной публикации".

Например, рассмотрим модель Entity для UserProfile: 

  public class UserProfile
  {
    public string UserName { get; set; }
    public bool IsAdmin { get; set; }
    public string EmailAddress { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
  }

Ваша страница профиля пользователя позволяет пользователю редактировать свое имя, фамилию и адрес электронной почты.

Недобросовестный пользователь может просто изменить форму, чтобы опубликовать "IsAdmin" вместе с другими значениями. Поскольку ваше действие ожидает ввода UserProfile, значение IsAdmin также будет отображено и в конечном итоге будет сохранено.

Вот отличная статья об опасностях недооценки и преувеличения .

Я не вижу ничего плохого в том, чтобы связывать модели сущностей напрямую с вашими методами [HttpGet].

1 голос
/ 13 октября 2010

На самом деле, это зависит, может быть, все, что вам нужно, это точно показать свою модель в пользовательском интерфейсе. тогда я не вижу смысла оборачивать это. Но в большинстве случаев, даже если вы думаете, что вам не нужно ничего менять в модели, прежде чем показывать это на экране, вам, возможно, придется сделать это в будущем. Таким образом, лучший способ состоит в том, чтобы разделить вашу точную модель и данные будущего просмотра. Это дает вам больше гибкости, если вам нужно что-то изменить (например, изменить структуру БД, но представление останется прежним)

0 голосов
/ 17 декабря 2015

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

Например, модель сущности Питера Дж. На методе редактирования вы можете просто сделать это: 

[HttpPost]
public ViewResult Edit([Bind(Include = "UserName, EmailAddress, FirstName, LastName")] User user)
{
    // ...
}

И просто пропустите элемент IsAdmin, чтобы он не использовался в сообщении.

Далее, как отмечено в сообщении в блоге, вы можете воспользоваться методом «черного списка» и сообщить своему контроллеру, какие поля вместо этого следует исключить: 

[HttpPost]
public ViewResult Edit([Bind(Exclude= "IsAdmin")] User user)
{
    // ...
}

Вы также можете разместить его над именем класса модели Entity, например: 

[Bind(Exclude="IsAdmin")]
public class UserProfile
  {
    public string UserName { get; set; }
    public bool IsAdmin { get; set; }
    public string EmailAddress { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
  }

Этот метод лучше подходит для случаев, когда вам нужно только исключить или включить несколько полей из моделей Entity.

0 голосов
/ 13 октября 2010

Да, по практике. Вы должны держать контроллер настолько тонким, насколько это возможно, и разделять каждую проблему.

...