Здравствуйте, Аноним, Вы писали:

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

А>MVC — это какой-то удивительный паттерн, который вроде все понимают, кроме меня, но что-то в этом понимании не то, ибо оно у всех разное. Если вы поищете изображения в гугле по запросу "MVC", вы увидите практически все варианты расположения стрелочек между квадратиками M, V и C. Если взять оригинальную статью по MVC, у автора Controller был подрисован к View, и вся его функциональность состояла в обработке ввода пользователя. То есть у автора MVC фактически была Model-View, а Controller — вспомогательный компонент View.

А>В какой-то момент в интерпретации, например, Microsoft, Controller стал таким важным, что встал между Model и View. А у других три компонента соединены в цикл с разными вариантами стрелочек.

А>У кого-то Controller — это вообще основная часть, где все делается, а model — это просто база данных.

А>Если говорить о тестировании, то, в принципе, ничего не мешает делать его без контроллера.

А>Пока что у меня в голове от MVC остался только какой-то сумбур.

А>То ли я тупой, то ли это какой-то заговор, то ли действительно с этими M*C моделями что-то не так.

Расскажу неполную, неточную и выдуманную историю MV* паттернов.

---

Часть первая. Зарождение MVC.

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

На заре графических ОС все приложения строились на основе цикла сообщений и обработки сообщений ОС. Еще не было компонентной модели, Delphi, C++ Builder, VB и прочих RAD тулов. Большая часть приложений была редакторами каких-либо документов, то есть предлагала средства для графического представления некоторой "модели". Надо понимать что это далеко не тоже самое, что толстый клиент многопользовательской системы (СУБД), там понятие модели другое и диктует другие паттерны.

Та вот по веянием ООП решили модель сделать объектом. Чтобы не нарушать SOLID не стали в модель вносить взаимодействие с пользователем. Чтобы отображать модель на экране использовался объект View, который просто брал данные у модели и рисовал. Все действия пользователей все так же попадали в виде событий в message loop. Для того чтоб в ООП стиле обрабатывать события придумали контроллер, который реагируя на события обновлял модель, а также пинал View для обновления интерфейса.

Вкратце суть MVC:
1) Управление приходит в Controller
2) Controller обновляет Model
3) Controller или Model (тут без разницы) пинает view
4) View отображает Model на экране
5) Model — объект, не база данных, не remote proxy, а обычный кусок памяти и набор методов.

Преимущества очевидны. Для изменения представления надо трогать только view, для изменения поведения только Controller.

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

---

Часть вторая. Зарождение MVP.

В середине 90-х годов огромную популярность приобрели RAD средства, использующие компонентную модель. Теперь не надо было вручную писать циклы обработки событий, достаточно было кинуть компонент на форму и он уже работал.
Разработчики ликовали, апологеты ООП были в глубоком унынии. Как же так, один компонент отвечает и за данные, и за рисование, и за обработку событий.
Кроме того это была эпоха корпоративных приложений, когда "модель" стала совсем не такой как в MVC. Теперь нельзя было просто изменять свойства объекта и сохранять в файл по нажатию кнопки.

Поэтому все что за пределами GUI объявили Model. Сам визуальный компонент назвали View, он показывает данные и обрабатывает ввод. Связующее звено между Model и View, которое подписывалось на события view и пинало его методы, а также обновляло данные назвали Presenter. Presenter обычно оказывается жестко привязанным ко view, так что никакого реюза не происходит.
Но есть заметное преимущество, в корпоративных приложениях Model оказывается на два порядка более изменчивым, чем в классическом MVC, поэтому прослойка между View и Model положительно сказывается на приложении.

Вкратце суть MVP:
1) Управление приходит во View
2) View вызывает presenter
3) Presenter общается с моделью
4) Presenter изменяет свойства View
5) Model — все что не GUI
6) Модель полностью отделена от представления

В зависимости от распределения обязанностей между View и Presenter придумали вариации Active\Passive View и еще чтототам.

---

Часть третья. реинкарнация MVC.

В 2000 году огромную популярность приобрел веб. Теперь это не только странички с надписью Under Construction, а платформа для приложений.

В вебе последовательность работы напоминает message loop. То есть приложение вынуждено реагировать на события (их гораздо меньше, чем в десктопе, поэтому веб гораздо проще). С другой стороны простой модели, как в классическом MVC в вебе в принципе не может быть.

Чтобы побыстрее насадить везде правильную архитектуру вытащили старый MVC, но слега его перетряхнули. View полностью отделили от Model (негоже из разметки страниц лезть в базу). В качестве View взяли шаблонизаторы HTML, Controller стал обрабатывать запросы, получать данные модели, и передавать их в шаблонизатор.

Вкратце суть web-MVC:
1) Управление приходит во Controller
2) Controller пинает Model
3) Controller передает данные на view
4) View генерит HTML
5) Model — все что не GUI

По сути это смесь MVP и MVC, но об этом никто не говорит, потому что уже не помнит сути изначального MVC.

Кстати это придумано далеко не Microsoft, Microsoft сделал свой web-MVC только в 2008 году и обозвал данные, передаваемые между Model и View, словом ViewModel. Но когда это вызвало путаницу с MVVM паттерном, о котором ниже, то ViewModel начал называть просто Model породив страшную неразбериху.

---

Часть четвертая. MVVM.

Я про MVVM узнал в 2008 году в контексте Microsoft и WPF. В отличие от предыдущих гуевых фреймворкв WPF умел делать декларативную двустороннюю привязку к данным.
Это позволило взять классический MVP, но в качестве view использовать чисто визуальные компоненты, которые содержат минимум поведения, а все поведение перенести в presenter.
При использовании привязки к данным presenter вырождался в класс, который выставлял наружу набор свойств и методов (команд). Этот класс начали называть ViewModel.
Одно из заметных отличий от MVP в том, что ViewModel не важно какой визуальный компонент привязывается к нему. Поэтому возможен реюз и большая гибкость в интерфейсе.

Вкратце суть MVVM:
1) Управление приходит во View, но программисту все равно, ибо view примитивен, для его View не существует.
2) View привязывается к ViewModel и все события попадают во ViewModel
3) ViewModel общается с Model и изменяет свои свойства
4) View меняет представление в зависимости от свойств ViewModel
5) Model — все что не GUI

Со временем подобный паттерн попадет во все уважающие себя GUI фрейиворки, в том числе на JavaScript.
Из-за традиционного бардака в JS как только MVVM не называют.

---

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

12/22/2013 12:20 PM, Kswapd пишет:

> Попробуй построить простую игру вроде тетриса. Архитектурно она должна
> состоять из двух процессов: model (решает, что делать после поступления
> реакции игрока) и view (графическое отображение и получение ввода).
Так ТС как бы и спрашивает от третьей букве С, а ты ему про то, что он
уже написал про MV.

P.S. Мое мнение все это по сути карго-культ. Количество слоев
определяется только задачей и ее реализацией, может быть 1 слой, 2, 3
или даже 10 и более.

Здравствуйте, Vzhyk, Вы писали:


V>P.S. Мое мнение все это по сути карго-культ.

примерно так, самое плохое тут это применение сего паттерна за религию и внедрение в жизнь людьми которые ничего или малочто поняли.
по сути это всеголишь пример как реализовать тонкую оболочку(UI) только с самым необходимым а весь функционал вытащить в независымй ни от
каких MFC&со обьект. принцып правильный и позволяет писать по нему самый лучший код но увы даже очень умные люди тут перегибают палку
поставив в приоритет сам паттерн а не решение задачи. это как раз то где я часто чистых информатиков не понимаю. похоже им важнее написать заумный код
следуя какойто моде/тренду чем понять суть дела и зачем это и технически грамотно это применять. естъ преимущества у сего паттерна, тотже юниттестинг
да он тут наиболее полно реализуем, другие вещи но есть и недостаток и ТС поддверждает это — сей инструмент многие не понимают и часто неправильно реализуют а это ещё хуже

Здравствуйте, Аноним, Вы писали:

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

http://blogs.rsdn.ru/it/4474407

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

MVC — это какой-то удивительный паттерн, который вроде все понимают, кроме меня, но что-то в этом понимании не то, ибо оно у всех разное. Если вы поищете изображения в гугле по запросу "MVC", вы увидите практически все варианты расположения стрелочек между квадратиками M, V и C. Если взять оригинальную статью по MVC, у автора Controller был подрисован к View, и вся его функциональность состояла в обработке ввода пользователя. То есть у автора MVC фактически была Model-View, а Controller — вспомогательный компонент View.

В какой-то момент в интерпретации, например, Microsoft, Controller стал таким важным, что встал между Model и View. А у других три компонента соединены в цикл с разными вариантами стрелочек.

У кого-то Controller — это вообще основная часть, где все делается, а model — это просто база данных.

Если говорить о тестировании, то, в принципе, ничего не мешает делать его без контроллера.

Пока что у меня в голове от MVC остался только какой-то сумбур.

То ли я тупой, то ли это какой-то заговор, то ли действительно с этими M*C моделями что-то не так.

А>То ли я тупой, то ли это какой-то заговор, то ли действительно с этими M*C моделями что-то не так.

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

Попробуй построить простую игру вроде тетриса. Архитектурно она должна состоять из двух процессов: model (решает, что делать после поступления реакции игрока) и view (графическое отображение и получение ввода). Данные передаются каким-нибудь IPC, например XML-RPC.

Здравствуйте, Аноним, Вы писали:
Python/Django
Это Model:

from django.db import models
class FileLoad(models.Model):
 file=models.FileField(upload_to='/var/www/pr/media/')
 image_file=models.ImageField(upload_to='/var/www/pr/media/')
class Question(models.Model):
   def __unicode__(self):
    return self.text
   text = models.TextField(max_length=2000)


class Choice(models.Model):
    question = models.ForeignKey(Question)
    count= models.IntegerField()
~

Это View:

html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<title>HOU</title>
{% load staticfiles %}
<body style="background-color:rgb(0,255,100)">
<div>
{% for var in request_list %}
<div style="background-color:green; padding:10px 5px 15px 20px; border:2px solid;
border-radius:25px;">
{{ var.text }}
</div>
{% endfor %}
<h2>END FORi
<form action="/pr/" method="post" enctype="multipart/form-data">{% csrf_token %}
<textarea wrap="hard" name="t1" rows=30 cols=70></textarea><br>
<input type="submit" value="send" />
</form>
<form action="/file_upload/" name="file" enctype="multipart/form-data" method ="post">{% csrf_token %}
<input type="file" enctype="multipart/form-data" name="upfile"/><br>
<div style="background-color:rgb(0,100,10)"><input type="submit">SEND
</div>
</form>
<a href="/load/">PASS TO LOAD</a>
</body>
</html>
~

Это Controller:

from django.http import HttpResponse, HttpResponseRedirect
from django.core.cache import cache
from django import forms
import json
from django.core.urlresolvers import reverse
from django.template import RequestContext, loader
from pr.models import Question, FileLoad
from django.core import serializers
from django.shortcuts import render_to_response
from pr.forms import UploadFileForm
import pr.ajax
def start(request):
    if request.method == 'GET':
     list=cache.get('FRONT','No')
     if list=='No':
      list = Question.objects.values('text')
      with open("/var/www/pr/media/xml",'wb+') as fl:
       fl.write("0")
       fl.close()
      cache.set('FRONT',list)
     temp=loader.get_template('pr/index.html')
     c=RequestContext(request,{'request_list':list,})
     return HttpResponse(temp.render(c))
    if request.method == 'POST':
     res=request.POST['t1']
     q=Question(text=res)
     q.save()
     list = Question.objects.values('text')
     temp=loader.get_template('pr/index.html')
     c=RequestContext(request,{'request_list':list,})
     return HttpResponse(temp.render(c))
def load(request):
 files=FileLoad.objects.values('file')
 temp=loader.get_template('pr/load.html')
 c=RequestContext(request,{'files':files,})
 return HttpResponse(temp.render(c))
def fileupload(request):
 if request.method == 'POST':
  f=request.FILES['upfile']
  real_load(f)
  return HttpResponse('<html><body bgcolor="green">SICCESS</body></html>')
 else:
   return HttpResponse('FACK')
def real_load(files):
 str='/var/www/pr/media/'+files.name
 q=FileLoad(file=files.name)
 q.save()
 with open(str, 'wb+') as fl:
  for ch in files.chunks():
   fl.write(ch)
  fl.close()
def Ajax(request):
  data=Question.objects.values('text')
  data2=[{'text':data[i]['text'].encode('utf-8')} for i in range(len(data))]
  dt=json.dumps(data2)
  if request.method=='GET':
   return HttpResponse(dt,mimetype='applicaton/json')
def ref(req):
 if req.method=='GET':
  js=pr.ajax.reference_html()
  return HttpResponse(js,mimetype='application/json')

А это передовая Controller:

from django.conf.urls import patterns, include, url
urlpatterns = patterns('',
    url(r'^pr/$', 'pr.views.start'),
    url(r'^load/$', 'pr.views.load'),
    url(r'^file_upload/$', 'pr.views.fileupload'),
    url(r'^ajax/$', 'pr.views.Ajax'),
    url(r'^reference_text/$','pr.views.ref'),   
    # url(r'^admin/', include(admin.site.urls)),
)

Здравствуйте, Аноним, Вы писали:

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

Фундаментально -- это отделение Model от View. Чтобы можно было безболезненно (в идеале) менять одно,
не ломая (переписывая с нуля) другое.

А>MVC — это какой-то удивительный паттерн, который вроде все понимают, кроме меня, но что-то в этом понимании не то, ибо оно у всех разное.
А>В какой-то момент в интерпретации, например, Microsoft, Controller стал таким важным, что встал между Model и View. А у других три компонента соединены в цикл с разными вариантами стрелочек.

Каждый может понимать, что-то свое.

А>У кого-то Controller — это вообще основная часть, где все делается, а model — это просто база данных.

Очень рекомендую вот эту книгу: они очень
подробно рассказывают про MVC со всяческими упражнениями. Главный упор делается на том, что
MVC является составным паттерном, т.е. паттерн, который состоит из паттернов,
а именно: CompositePattern, ObserverPattern and StrategyPattern. Тут чуточку подробнее. Соответственно смотреть на это можно и так: вышеозначенные паттерны (composite, observer, strategy),
который играют огромную роль в дизайне ПО и проч., являются частными случаями MVC. Поэтому MVC и является
одним из фундаментальных паттернов, знать и понимать который крайне желательно. Еще раз рекомендую приведенную выше книгу по части объяснения MVC, очень доходчиво и внятно (я читал англоязычную версию).


А>Пока что у меня в голове от MVC остался только какой-то сумбур.

Ну представьте себе автомобиль: модель -- это то, что под капотом, панель датчиков (тахометр, спидометр, бензин,
масло и проч.) -- view, педали -- controller. То есть, многие взаимодействующие компоненты можно описать при помощи
MVC паттерна. Это действительно фундаментальный паттерн. Например, можно было бы разложить по MVC триаду автор, книга, читатель, но это похоже уже перебор...

Здравствуйте, Аноним, Вы писали:

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

Промежуточный слой не между Model (модель данных) и View (вид данных), промежуточный слой это Model (модель данных), между Data (данные) и View (вид данных).

Например, есть некие данные:

Data <=> Model <=> View

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

А дальше пошли вариации на эту тему:
Model-View-Controller
Model-View-Presenter
Model-View-ViewModel

Контроллер это то, что можно вынести из модели в отдельный функционал.

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

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

В идеале модель содержит только бизнес логику. Контроллер адаптирует
интерфейс модели для реальных задач ПО. При этом контроллеры могу быть
многоуровневыми. Чётких границ конечно нет.