Здравствуйте! почитал про шаблон MVC, много всего написано, правда примеров раз, два и всё, причём примеры все ну прям простейшие и в написании реальных сайтов не помогут! Есть задумка написать простенький сайт в целях самообучения, вобщем в нём несколько страничек: Главная, Уроки, Новости проекта. Написал роутер, который выбирает нужный контроллер и его метод. Дальше нужно писать контроллеры и модели, так вот, как тут определить обязанности контроллера, ну то-есть например:
контроллер должен передавать в представление данные и он один и тот же задействован во всех трёх страницах сайта(естественно данные из базы данных берутся из модели)?
Либо для отображения главной страницы сайта нужен свой контроллер, для новостей свой, а для уроков свой?

Вот кто писал сайты на MVC подскажите пожалуйста как в профессиональной разработке это делается, какой контроллер и за что отвечает, как вы делали???

Просто есть пример создания сайта визитки или магазина на MVC, но они настолько простые, что там всего из одной страницы сайт сделан((

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

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

понятно! Спасибо большое за ответ! значит тогда получается, что если не пользоваться фреймворками, а писать свой код, то полюбому это изобретение велосипеда, но зато очень интересное!)

Serdg http://habrahabr.ru/post/150267/, не?

Guest

Если вы писали десктоп приложения без использования визуальных средств то естественным образом были вынуждены делить код на несколько частей, а именно на интерфейс и обработку для начала. Интерфейс естественным образом распадается на еще две части - на ввод данных и на вывод данных.

Например окно. Окно надо нарисовать, нарисовать в нем кнопки, команды, на кнопки и команды повесить события, события запрограммировать. - это типа контроллер. Затем надо определить что куда в этом окне будет выводиться и в каком виде. - типа view. Все что валится из контроллера надо обработать согласно предустановленным данным, согласно логике приложения, согласно полученным данным - этим занимается модель. В которую данные из контроллера попадают не важно как, из которой данные в представление попадают не важно как. Реализация потоков к паттерну не относится.

Визуальные средства предоставляют готовый интерфейс input/output - controller/view в современных терминах, разраб занимается только процессингом - моделирует поведение апликухи согласно плану.

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

В эти "стандартные" каналы вы внедряете свои коды и тем самым модифицируете стандартные средства ввода/вывода под свои нужды. Между вводом и выводом рисуете свои модели (логику приложения, gameplay, короче).

Внедрять коды можно по-разному. Можно простым include() - копипастой куска скрипта в другой скрипт, - можно наследованием свойств и методов родительского (стандартного) класса, то есть расширением его свойств и методов для конкретной потребности по обстоятельствам.

Стандартный класс это не stdClass; конечно, это _типа_ стандартное средство ввода или вывода в рамках данной рамки (framework). Рамка которая имеет еще и стандартные модели - это CMS.

Я, $^#ка неделю бился над пониманием что такое MVC, потому что закончил программировать без visual лет 15 назад, и visual свое дело за этот период сделало. Последний раз, чуть больше года назад столкнулся-таки с задачей под которую не было выделено визуальных средств и в общем-то без особых проблем ее решил и даже неплохо.

Средства были такого рода:

function createDialog() {
	var dlg = new Window('dialog', 'Art Mask');
	dlg.frameLocation = [prefs.windX, prefs.windY];
	
	dlg.onMove = function() {
		if(dlg.active) {
			prefs.windX = dlg.frameBounds.x;
			prefs.windY = dlg.frameBounds.y;
		}
	}
	
	dlg.onClose = function() {
		savePrefs(prefs);
	}
	
	// PRESET LIST AND MANAGE IT
	dlg.grpPresets = dlg.add('group');
	with(dlg.grpPresets) {
		orientation = 'row'; 
	
	// Presets list
		lstPres = add("dropdownlist");
		lstPres.preferredSize = [150,20];
		for(var i = 0; i < presets.length; i++) {
			lstPres.add("item", presets[i].name);
		}
		lstPres.selection = cur; // notify
		lstPres.onChange = function(){
			fillValues(lstPres.selection.index)
		};
		
	// Manage presets commands
		lstCmd = add("dropdownlist");
		lstCmd.preferredSize = [100,20];
		popUiList(lstCmd, presCmdList, 0);
		lstCmd.onChange = function() {
			if(lstCmd.active) managePresets(this, lstPres);
		};
	}

// еще туева хуча дефиниций ...

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

Ну вот, рамки, типа такого Window (у них это Application) и предоставляют.

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

Я блин не припомню случая чтобы WScript заработал с первого раза, или даже с десятого, несмотря что ява-скрипты я как говорится, имел куда хотел. Вроде как все на JS, но настолько через ж, что даже alert() приходится делать функцией alert(msh) { WScript.echo(msg) }

И последнее. Факт что на PHP начали ваять stdIn/stdOut говорит не в пользу ваятелей. И вообще не в пользу. PHP это скрипт, это Personal Home Page/Forms Interpreter. За который, конечно, большинство немедленно уцепились, потому что осилить C не могли.

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

Однако свободное общество пошло своим путем. Как обычно.

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

Динозавр между тем доказывает что прав, становясь все динозаврее и динозаврее. Ящерицам никак не дорасти.

По теме. Роутер это элемент паттерна и точка. Можно извиваться называя его фронт-контроллером и другими эвфемизмами, факт останется лежать. Без роутера контроллер, который типа за input отвечает, ни за что не ответит никогда.

Да-да, все народные герои.

Короче, интуиция начала подсказывать, но толком понять что пока не могу, не хватает знаний матчасти. Вот снип:

# map the /blog/post/:id path to the blog/post controller.
$router->add(new routing\router\route('/blog/post/:id', 'blog/post'));

http://avendiart.wordpress.com/2013/03/30/...php-mvc-router/

Вопрос. Можно ли использовать namespace непосредственно в качестве роутера?

Берем path_info, или вообще элемент запроса который изображает путь и используем этот путь как путь. Как мы делали бы с файлами, разве так же нельзя делать с кусками кода?

Я к тому что роутера быть не должно. Input'ом должен заниматься контроллер.

Если кто не понял, то input это все что передается в качестве аргументов. Все что идет после имени скрипта - это его input.

Первым делом заподозрил что namespace не так просто определить для использования через переменную. Но пишут все реализуемо http://stackoverflow.com/questions/6404374...able-namespaces