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

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

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

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

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

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

Ответ 1

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

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

Тем не менее, IMHO это означает НЕ означает, что вы должны просто разместить всю связанную с БД логику внутри слоя контроллера. Это называется подходом к "жиросжигателю", и это дорога, которая во многих случаях приводит к раздутому, неподдающемуся безопасности коду. Вы можете использовать его для простых проектов CRUD, но что-либо кроме этого потребует существования реальной "Модели".

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

Edit

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

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

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

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

Ответ 2

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

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

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

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

Большинство современных фреймворков 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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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