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

Question

Я новичок в этом, так что терпите меня. В последнее время я использовал один MVC-фреймворк в нескольких проектах, и через некоторое время я разочаровался в ощущаемой полезности «Модели» в MVC.

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

Если вся логика должна быть размещена внутри контроллера в первую очередь, я не вижу никакого смысла для модели, особенно Active-Record. У нас уже есть язык, который настолько надежен и прост в использовании для связи с базой данных, я прав? Это называется SQL. Для меня, когда модели реализованы как active-record, их полезность зависит от того, хотите ли вы, чтобы ваше приложение помещалось в нескольких базах данных.

Итак, я спрашиваю: если вы используете только одну базу данных, зачем беспокоиться о моделях и активных записях? Почему бы просто не использовать SQL? Почему дополнительный уровень сложности? У вас, ребята, есть какие-нибудь примеры из практики / истории из реальной жизни, где модели действительно могут работать лучше, чем просто использование класса базы данных и отсутствие SQL?

Опять же, извините, если я выгляжу таким невежественным, но я действительно не знаю, почему Модели важны. Спасибо за ответ.

Answer 1

Во-первых, вы предполагаете, что уровень модели обязательно использует какой-то ORM, чтобы абстрагировать SQL.Это не так: вы можете создать слой модели, который слабо связан со слоем Controller, но тесно связан с конкретной СУБД, и поэтому избегайте использования полнофункционального ORM.

Существуют некоторые библиотеки ORMкак Hibernate (Java), NHibernate (.NET), Doctrine (PHP) или ActiveRecord-Rails (Ruby), которые действительно могут генерировать все реальные операторы SQL для вас;но если вы считаете, что ORM не нужен, и вы хотите определить все операторы SQL вручную, не используйте их.

Тем не менее, ИМХО, это действительно НЕ означает, что вы должны просто разместить все своиЛогика, связанная с БД внутри уровня контроллера.Это называется подходом «жирного контроллера», и это путь, который много раз ведет к раздутому, не поддерживаемому коду.Вы могли бы использовать его для простых проектов CRUD, но все, что за этим будет требовать существования настоящей «Модели».

Кажется, вам небезразличен MVC.Пожалуйста, прочитайте также кое-что о TDD.Один мудрец однажды сказал: « устаревший код - это код без тестов ».Когда вы узнаете, что автоматизированные модульные тесты так же важны, как «реальный» код, вы поймете, почему в корпоративном приложении так много уровней и почему ваш уровень модели должен быть отделен от контроллера.Блок кода, который пытается сделать все (представление, бизнес-логика, сохранение данных) просто не может быть легко протестирован (и, между прочим, не отлажен).

Редактировать

«Модель» - это немного нечеткий термин.В зависимости от того, где вы смотрите, это может означать что-то немного другое.Например, программисты PHP e Ruby часто используют его как синоним Active Record , что не совсем точно.Некоторые другие разработчики, похоже, считают, что «модель» - это просто некая модель DTO , что тоже неверно.

Я скорее использую определение модели, как видно из Википедии:

Центральный компонент MVC, модель, фиксирует поведение приложения с точки зрения его проблемной области, независимо от пользовательского интерфейса.Модель напрямую управляет данными, логикой и правилами приложения.

Таким образом, модель является самым большим и самым важным уровнем в большинстве приложений MVC.Вот почему он обычно делится на подуровни: домен, сервис, доступ к данным и т.Модель обычно выставляется через домен, потому что именно там вы найдете методы, которые вызовет ваш контроллер.Но уровень доступа к данным также относится к «модели».Все, что связано с постоянством данных и бизнес-логикой , принадлежит ему.

Answer 2

Это вообще не невежественный вопрос! Просто тот факт, что вы спрашиваете об этом, а не просто игнорируете всю теорию MVC и делаете все, что вам угодно, приятно. : -)

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

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

Чтобы привести более конкретный пример (если не полностью реалистичный): теоретически вы могли бы написать все ваше приложение так, как вы извлекали все данные с помощью SQL-запросов. Но позже вы поняли, что хотите использовать какой-нибудь движок noSQL (CouchDB и т. Д.), Потому что вам нужно горизонтальное масштабирование.

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

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

И это только на скучной складской части. При использовании чистого SQL намного сложнее определить взаимодействия между объектами вашего приложения (т. Е. Бизнес-логикой), потому что вы просто не будете делать это в SQL (возможно, в любом случае).

Это не идеальное объяснение (отнюдь нет), но я надеюсь, что это поможет.

Answer 3

В большинстве реальных ситуаций данные, поступающие от пользователя, не попадают прямо в базу данных.

Он часто должен быть проверен, отфильтрован или преобразован.

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

Другими словами, слой Model отвечает - или "знает" - как должны обрабатываться данные.

В большинстве современных сред MVC предусмотрены способы указания контрактов в соответствии с требованиями достоверности данных, такие как Rails.

Вот пример из http://biodegradablegeek.com/2008/02/introduction-to-validations-validation-error-handling-in-rails/:

class Cat
  validates_inclusion_of :sex, :in => %w(M F), :message => 'must be M or F'
  validates_inclusion_of :vaccinated, :in => [true,false]
  validates_inclusion_of :fiv, :in => [true,false]
  validates_inclusion_of :age, :within => 1..30
  validates_each :weight do |record, attr, value|
      record.errors.add attr, 'should be a minimum of 1 pound' if value and value  /^[01][0-9]\/[0-9]{2}\/[0-9]{4}$/
  validates_length_of :comment, :allow_blank => true, :allow_nil => true, :maximum => 500
end

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

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

Можно еще много сказать об этом, но я чувствовал, что хочу затронуть вопрос, который кажется мне важным, мотивированным практическим опытом:)

Answer 4

Модели должны содержать всю вашу логику.Контроллер отвечает только за логику, связанную с взаимодействием с пользователем.Все связанные с доменом функции (так называемая «бизнес-логика») должны быть размещены в модели и отделены от кода контроллера.Таким образом, вы можете добиться лучшего разделения проблем и повторного использования кода.

Например, допустим, вы пишете приложение, позволяющее пользователям вводить информацию о себе и получать рекомендации по питанию.

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

С другой стороны, вы помещаете код для входа в систему пользователей, показывает форму, собираете данные формы, проверяете ее в контроллере.Таким образом, например, вы можете позже добавить API в ваше приложение (которое использует другой код для аутентификации, получения данных от пользователя, проверки и т. Д.) И повторно использовать код для генерации результатов (из модели).

Это всего лишь пример того, для чего модель подходит.

Answer 5

Я всегда связываю Модель с данными независимо от того, где они присутствуют или как они представлены. В MVC V отображаются данные, а C ручки меняются Даже если у вас есть все данные, которые будут представлены на экране в HashMap внутри вашего контроллера; этот HashMap будет называться Model.