Изпечатай

[VladSun]

За прочит http://bg.wikipedia.org/wiki/Model-View-Controller

Ще се опитам да дам и аз мое тълкуване на MVC архитектурата:

* Модел - съдържа единствено и цялата "бизнес" логика - "вътрешното" състояние на системата. Моделът не се интересува от това как е представен (т.е. неговите данни и вътрешно състояние) пред потребителя (който може да е и друг софтуер, не е задължително човек). Моделът също така не се интересува от къде идват новите данни и команди за промяна на състоянието му. Моделът се грижи за съхраняването и извличането на данните (ДБ, файлове и т.н.) ;

* Изглед - всеки един от тези компоненти има достъп до всички публични данни и методи на Модела и определя кои от тях и как да бъдат изобразени;

* Контролер - всеки един от тези компоненти има достъп до всички публични данни и методи на Модела. Контролерът също така определя какво е действието предприето от потребителя и какви са новите данни предоставени от потребителя. В зависимост от исканото действие, Контролерът извиква определена команда и/или променя определени данни на Модела. Контролерът също така решава кой Изглед ще се използва за визуализирането на Модела.

Защо се прави всичко това? Ще се опитам да изясня чрез пример:

Искаме да направим софтуер за прост калкулатор - да може да вади, събира, умножава и дели числа. Създаваме web вариант на този софтуер. Ако сме следвали MVC архитектурата, то ще можем:

* да променим форматът на резултата (прим. в PDF) само чрез добавяне на нов компонент за Изглед - без да променяме нищо друго.
* да създадем CLI вариант като само променим компонентите за Контролер/Изглед.

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

Съществува така наречения Front Controller - това е специален Контролер, който осигурява една единствена входна точка (представете си main() в C ) за целия софтуер. Front Controller-а определя кой Action Controller трябва да се извика и да му се предадат входните данни. Action Controller са Контролерите, които вие ще трябва да пишете и те ще се грижат за описаните в горната дефиниция действия.

Добре е Моделът да бъде напълно капсулиран - т.е. да няма възможност за пряко модифициране или четене на данните му. Това се постига чрез използването на данни с ограничен достъп (protected/private) и публични методи за тяхното модифициране/четене.

[VladSun]

Ще дам вариант за реализирането на примерът за калкулатор. Ще използвам CodeIgniter-подобни дефиниции, защото смятам, че така ще бъде най-разбираемо.

Модел

Код

GeSHi (PHP):
class Calculator_Model extends Model
{
	protected $errors	= array();
	protected $result	= 0;
 
	public function add($a, $b)
	{
		if (!$this->validate($a) || !$this->validate($b))
			return;
 
		$this->result = $a + $b;
	}
 
	public function substract($a, $b)
	{
		if (!$this->validate($a) || !$this->validate($b))
			return;
 
		$this->result = $a - $b;
	}
 
	public function multiply($a, $b)
	{
		if (!$this->validate($a) || !$this->validate($b))
			return;
 
		$this->result = $a * $b;
	}
 
	public function divide($a, $b)
	{
		if (!$this->validate($a) || !$this->validate($b))
			return;
 
		if ($b == 0)
		{
			$this->errors[] = "Деление на нула";
			return;
		}
 
		$this->result = $a / $b;
	}
 
	public function hasError()
	{
		return count($this->errors) > 0;
	}
 
	public function getErrors()
	{
		return $this->errors;
	}
 
	public function getResult()
	{
		return $result;
	}
 
	public function clear()
	{
		$this->result = 0;
		$this->errors = array();
	}
 
	protected function validate($a)
	{
		if (!is_numeric($a)
		{
			$this->errors[] = "Операндът не е число";
			return false;
		}
		return true;
	}
 
}

Controller

Код

GeSHi (PHP):
class Calculator extends Controller
{
	public function __construct()
	{
		parent::__construct();
		$this->load->model('Calculator_Model', 'calculator'); // зареди инстанция на класа Calculator_Model в $this->calculator
	}
 
	public function index()
	{
		$this->calculator->clear();
		$this->load->view('input.html.php', $this->calculator);
	}
 
	public function add()
	{
		$this->calculator->add($_POST['a'], $_POST['b']);
		$this->load->view('result.html.php', $this->calculator);
	}
 
	public function substract()
	{
		$this->calculator->substract($_POST['a'], $_POST['b']);
		$this->load->view('result.html.php', $this->calculator);
	}
 
	public function multiply()
	{
		$this->calculator->substract($_POST['a'], $_POST['b']);
		$this->load->view('result.html.php', $this->calculator);
	}
}

View input.html.php

Код

GeSHi (PHP):
<!DOCTYPE html  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<title>Calculator</title>
	</head>
<body>
	<form method="post" action="/calculator/add">
		<input type="text" name="a" value=""/> + <input type="text" name="b" value="" /> = ?
		<input type="submit" value="Изчисли">
	</form>
 
	<form method="post" action="/calculator/substract">
		<input type="text" name="a" value=""/> - <input type="text" name="b" value="" /> = ?
		<input type="submit" value="Изчисли">
	</form>
 
	<form method="post" action="/calculator/multiply">
		<input type="text" name="a" value=""/> * <input type="text" name="b" value="" /> = ?
		<input type="submit" value="Изчисли">
	</form>
 
	<form method="post" action="/calculator/divide">
		<input type="text" name="a" value=""/> / <input type="text" name="b" value="" /> = ?
		<input type="submit" value="Изчисли">
	</form>
 
</body>
</html>

View result.html.php

Код

GeSHi (PHP):
<!DOCTYPE html  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
		<title>Calculator</title>
	</head>
<body>
	<?php
		if ($calcualtor->hasError())
		{
			foreach ($calculator->getErrors() as $errorMessage)
			{
				echo '<div class="error">'.$errorMessage.'</div>';
			}
		}
		else
		{
			echo '<div class="result">Резултът е: '.$calculator->getResult().'</div>';
		}
	?>	
 
	<a href="/calculator/index">Към калкулатора</a>
</body>
</html>

[b2l]

И една картинка за да стане по-ясно:

[VladSun]

Честно казано не съм много съгласен с тази картинка - обикновено Изгледът има пълен достъп за четене на Модела, а Контролерът се прави възможно "най-тънък".

Освен това MVC е често даван като пример за приложението на Observer шаблона - Изгледът "наблюдава" Модела за промени и при възникването на такива се обновява.

Тази картинка е по-близо до моите разбирания:

http://upload.wikimedia.org/wikipedia/commons/2/2e/ModelViewControllerDiagram.svg

[senser]

Нека да пробвам да дам и аз моите 20 ст. по темата - те са изцяло базирани на опита ми, който имам с CakePHP. Там картинката на backtolife пасва доста повече от тази на VladSun, в смисъл, че почти никога в изгледа не достъпваш директно данни от модела. Другото, което ми прави впечатление в примера на VladSun, може би не е свързано директно с MVC архитектурата, но все пак: използването на $this->validate($a),  за да не се повтаря във всяка функция е удобно да се изнесе в отделна callback функция, която да се изпълнява преди всяко действие (или след него, според зависи).

[VladSun]

Да, съгласен съм, че MVC архитектурата може да се интерпретира по различен начин. Един от основните избори при нея е колко и каква работа да се върши в Контролера - "тънък" или "дебел" Контролер. Моят личен избор е за "тънък" Контролер.

По отношение на "validate" - исках да дам по-прост пример, конкретизиран върху MVC шаблона.
В реалните случаи е най-добре Моделът да съдържа инстанция на Validator клас, с който да се проверяват универсални ограничения, несвързани с бизнес логиката ( validate() в този случай ), а самият Модел да проверява за валидност по отношение на бизнес логиката - if ($b == 0) блокът в този случай.

[VladSun]

Явно имаме потребители на достатъчно много MVC PHP frameworks, та предлагам всеки да започне с описание на инсталацията и bootstrap-а на избраната от него.

Аз поемам CodeIgniter

Така ще можем да помогнем на някои от потребителите в този форум да се отърват от спагети-кода, който имат в момента.

Идеята ми хрумна заради скорошната тема на toti84 - http://www.linux-bg.org/forum/index.php?topic=37436.0

[VladSun]

Една добра поредица от статии за "начинаещи" :

http://blog.dmcinsights.com/series/understanding-mvc/

[ivo3d]

Честно казано не съм много съгласен с тази картинка - обикновено Изгледът има пълен достъп за четене на Модела, а Контролерът се прави възможно "най-тънък".

Освен това MVC е често даван като пример за приложението на Observer шаблона - Изгледът "наблюдава" Модела за промени и при възникването на такива се обновява.

Тази картинка е по-близо до моите разбирания:

http://upload.wikimedia.org/wikipedia/commons/2/2e/ModelViewControllerDiagram.svg

Идеята да има директна връзка между модела и темплейта звучи добре, всъщност се спестява доста код. Но все пак не ми вдъхва много доверие, можеш ли да ми покажеш framework, в който това е описано в документацията като практика, аз досега не съм срещал - във framework-а, който пиша в момента за няколко специфични, но идентични проекта също няма да го предвиждам това като възможност. Още повече там по темплейтите ще пипат хора, на които предпочитам да им давам готови масиви и да не знаят имената на моделите и как се борави с тях...

И аз се стремя към "тънък" контролер, валидациите и връзките между таблиците са описани в моделите, кеширането също. В контролера само викам нужния модел, записвам/взимам информация и я пращам към view-to (или към responce обекта директно, ако ми трябва json или xml например). Също така подавам form класове към темплейта и това е... Helper-ите се зареждат "мързеливо" в темплейта, така че и за тях контролера няма грижа. Но информацията винаги минава през контролера.

Все пак ще ми е интересно да видя това което казваш реално, не бях се замислял досега и ми изникват доста въпроси.

[VladSun]

И аз много често съм използвал предаване на данни от контролера към изгледа чрез използването на асоциативен масив. Наистина по този начин се постига някакво ограничаване на възможностите за грешка от страна на дизайнерите.
Но, все пак :

Код

GeSHi (PHP):
class User extends Controller
{
	public function save()
	{
		if (empty($_POST['submit']))
		{
			$this->load->view('user/save/form');
		}
		else
		{
			$user = new UserModel();
			if ($user->save($_POST['id'], $_POST))
			{
				$this->load->view('user/save/success');
			}
			else
			{
				$this->load->view('user/save/form', array
				(
					'name'	=> $user->getName(),
					'phone'	=> $user->getPhone(),
					'email'	=> $user->getEmail(),
					'errors'=> $user->getErrors(),
				));
			}
		}
	}
}

Вижда се, че де факто превръщаме обекта на модела в асоциативен масив.

Второто нещо, което не ми харесва е да се слага логика както в контролера, така и в изгледа:

Код

GeSHi (PHP):
			$this->load->view('user/get', array
			(
				'name'		=> $user->getName(),
				'phone'		=> $user->getPhone(),
				'email'		=> $user->getEmail(),
				'isAdult'	=> $user->getAge() > 18
			));

или

Код

GeSHi (PHP):
echo $user->getAge() > 18 ? 'OK' : 'Not OK';

По-добре е да се добави isAdult() метод в модела и да се вика в изгледа (или контролера в твоя случай).

Функциите на контролера според мен са няколко:
- да създава контекст за модела (т.е. какво ще се прави);
- определя как и от къде ще се взимат входните данни и предаването им на модела (GET, POST, PUT и т.н. в света на www);
- зареждането на съответния изглед за контекста и предаването на модела към изгледа;

Ако предаваш директно модела на изгледа, то при разширяването на модела ще се пипа само в кода на изгледа.

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

Всичко това особено добре си проличава, когато приложението не е "stateless" (имам предвид HTTP протокола) - прим. desktop приложение. Тогава Observer шаблона е най-подходящата връзка между модела и изгледа.

[VladSun]

По отношение на притесненията ти за достъпа до модела от страна на дизайнерите, би могъл да използваш някакъв вид wrapper за да ограничиш действията с него:

Код

GeSHi (PHP):
class ReadOnlyWrapper
{
	protected $object = null;
 
	public function __construct($object)
	{
		if (!$object)
			throw new Exception('Object instance required.');
 
		$this->object = $object;
	}
 
	public function __set($property, $value)
	{
		throw new ReadOnlyException('Object oproperties have read only access');
	}
 
	public function __get($property)
	{
		if (is_object($this->object->{$property}))
			return new ReadOnlyWrapper($this->object->{$property});
		else
			return $this->object->{$property};
	}
 
	public function __call($method, $arguments)
	{
		if (substr($method, 0, 3) === 'get')
			call_user_func_array(array($this->object, $name), $arguments);
		else
			throw new ReadOnlyException('Method ['.  get_class($this->object).'->'.$method.'] called is not a read only one.');
	}
}
 
class ReadOnlyException extends Exception {}
 

И съответно в контролера:

Код

GeSHi (PHP):
$this->load->view('user/save/form', new ReadOnlyWrapper($user));

[ivo3d]

Явно в 2:30 е по-добре да се спи Не съм те разбрал, аз го правя по същия начин, естествено, че няма да разкъсвам модела в контролера и да пращам отделни фрагменти на view-то (макар, че така е най-strict да го кажем)... Пращам моделите на темплейта, в контролера единствено ги зареждам и ги предавам натам и после темплейта да си взима каквото му трябва. Освен разбира се в случаите, когато обработвам информация от get/post, но тогава теплейта така или иначе не играе роля.

Но все пак разговора ме подсеща, че ще е хубаво когато се обръщам към модел от темплейт, да е само read-only и по-късно ще го измисля да стане без допълнителни класове. Предвид, че контролера и view класа ги зареждам с reflection, няма да е особен проблем да проверявам какво се случва и кой кого и откъде вика.

[VladSun]

//offtopic

Но все пак разговора ме подсеща, че ще е хубаво когато се обръщам към модел от темплейт, да е само read-only и по-късно ще го измисля да стане без допълнителни класове. Предвид, че контролера и view класа ги зареждам с reflection, няма да е особен проблем да проверявам какво се случва и кой кого и откъде вика.

Ще ми е интересно да покажеш какво правиш точно. Имахме дискусия преди време - гледам, че не си се включвал в нея:
http://www.linux-bg.org/forum/index.php?topic=28455.0

[ivo3d]

Не съм, аз от около година пиша сериозно OOP, а и тогава бях позабравил малко линукса (заради едни аудио проекти, трябваше ми боза постоянно и бях занемарил убунтото)... Както и да е.

В момента, както казах, пиша собствен framework като идеята му (поне засега) не е за публично ползване, но нищо не ми пречи да я пусна. Общо взета има доста идеи, взаимствани от kohana и doophp. От кохана дори има някои неща, които съм изкопирал почти дословно, например utf8 функциите. От doohphp всъщност заимствах идеята повечето неща да са singleton и да се зареждат "мързеливо" - демек 1 път и то само когато трябва (ако потрябва).

Има и ORM, който всъщност е проекта phpActiveRecord с някои промени.

Framework-а изисква php 5.3, защото се използват namespaces и някои други нововъведения в 5.3. Главно гоня производителност, че съм се патил от годзилогрухти като zend и cake. Засега с използване на бази данни съм успял да постигна около 50% по-ниска производителност от чисто php, но в момента повечето неща са в разработка и или се зарежда съвсем малко код или не се зарежда нищо... Но ще гледам да не клякам повече от 60-65% под чистото php. При големите рамки разликата е в пъти, обикновено десетки, но не бива да се правят сравнения, тъй като при мен функционалността също е в пъти (десетки) по-малка от големите рамки, а и на мен идеята не ми е да се получи нещо универсално, а да решава точно конкретни задачи.

Всъщност каква ми е идеята - освен производителност, исках да знам на абсолютно всеки ред какво се случва, както се вика на ниво kernel. Не, че не мога във всеки един framework да разбера какво се случва, но общо взето всеки програмист има свой начин на мислене и за мен в доста framework-ове има неща, които са ми абсолютно нелогични, а има фрагменти, които просто не мога да разбера защо са написани точно така...

Другата причина да започна свой framework - трябва ми hmvc, ама не точно. Например на мен ми предстоят няколко идентични уеб приложения - сайт, който рекламира и продава услугата и самата услуга, като всеки потребител има поддомейн (виртуален разбира се)... Например:

http://www.webapp.bg рекламира и продава услугата
ivan.webapp.bg; dragan.webapp.bg - представляват самото уеб приложение
http://www.webapp.bg/admin - 3-то уеб приложение, с които да администрирам потребителите, както и www сайта.

Трябват ми едни и също модели, но различни контролери, темплейти, layout, acl. Дори и различна multilanguage поддръжка, примерно в ivan.webapp.bg и dragan.webapp.bg и http://www.webapp.bg искам български и английски, а в http://www.webapp.bg/admin/ не ми трябва.

За целта съм ги разделил на отделни модули, които ползват един framework и едни и същи модели, но останалите ресурси са си за всеки модул отделно. Например:

Код

GeSHi (PHP):
 
$modules = array(
	'site' => array(
		'type' => 'dir',
		'path' => '/',
		'multi-language' => 'yes'
	),
	'admin' => array(
		'type' => 'dir',
		'path' => '/admin/',
		'multi-language' => 'no'
	),
	'webapp' => array(
		'type' => 'subdomain',
		'include' => '*',
		'exclude' => 'feed',
		'multi-language' => 'yes'
	)
);
 
 

Както се вижда, има 3 модула, като за всеки си има директория със всичките ресурси. "site" се отделя на база път, като пътя е / в http://www.webapp.bg (webapp.bg). "admin" модула се зарежда, когато имаме http://www.webapp.bg/admin/. А "webapp" когато имаме какъвто и да е поддомейн ('include' => "*") освен 'feed' ('exclude' => 'feed'). Feed е просто пример, не е с някаква конкретна цел. Може да се зарежда и по обратната логика. Например ако имаме feed.webapp.bg, и няма конфигурация, която да е специално за feed, ще се зареди "site" модула. Затова накрая слагам един модул 'feed', в който 'exclude' e '*', а 'include' е 'feed'. Имам и един комбинирам тип, който е за път в поддомейна. Може би звучи объркващо, но на мен точно това ми трябва.

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

И последната причина, за която пиша framework (но не на последно място) - опит. За 2 седмици научих толкова нови неща, аз за сефте ползвам сериозно exceptions примерно. Досега съм ползвал try/catch, но никога не съм се замислял моите класове да плюят изключения.

[ghoof]

Брех пичове много хубаво си хортувате тук, ама май забравяте нещо. А? А това дето забравяте е, че сте изостанали с 10 години. Поне. Казвам поне да не Ви обидя. За MVP да сте чували? Не не го измислил М$, а IBM и Aplle го ползва в своя Smalltalk даже. А там ясно си е казано- вюто няма никаква работа с модела. Да така се спестява код, ама това си е процедурно писане в обекти, а не нещо ползваемо. Така, че никаква работа на вюто и точка. И какви са тия песни вюто да определя де, какво да се вижда. Това си е работа на контролера. Всички глави го казват. Вюто (изгледа) единствено и само представя данни, нищо друго. Изобщо скучна работа- няколко цикли вместени в html на дизайнерчето. Кой, какво и кога има право да вижда си е работа само на контролера и никой друг. Той определя и какво да даде на модела и какво от него и къде да даде на изгледа. А пък модела от своя страна си сверява и валидира там, каквото са му подали, обработва и връща. Ей толкова е просто, ама тук яко мешате спатийте и правите глупости.