Где можно посмотреть пример готового сайта на Express.js?
Доброго дня!
Где можно посмотреть готовый пример блога / новостника / форума / сайта / etc на Express.js ? Если ли открытые репозитории, или возможно вы согласитесь поделиться своей наработкой.
С API express'а знаком, задача привить хороший вкус к правильной архитектуре приложения и разбития его по шаблону MVC.
Sails, Keystone и прочие генераторы щупал, но это не дает понимания архитектуры.
Так же сейчас интересует:
* В какой момент генерировать meta SEO (в Middleaware или в Model)?
* На какие логические части разбивать view.
* Как слелать удобоворимую админку с хуками.
* Какую организацию папок использовать.
* Что пихать в Model, а что в Controller
Не считаю идеальной организацией и архитектурой, но вот пример: https://github.com/madhums/node-express-mongoose-demo
Можно посмотреть, как сделана авторизация, как прикручены тесты, как контроллеры ходят в модель и т.д. Там же есть пара ссылок, из которых тоже можно что-то почерпнуть.
фреймворк это не архитектура, это фреймворк, инструмент, который решает общие проблемы возникающие у разработчиков (надо например авторизацию запилить, маршрутизацию и т.д.)
Сергей Протько: На гите искал, и не раз. Но там в основном такие же "догадчики" как и я, городят свои велосипеды. Или же только каркас проекта.
Я же хотел покапаться в закончаноп продукте, так как WP'шное пролое до сих пор не дает мне покоя, и мозг до сих пор старается рабоать на хуках. А хотелось делать "как надо"
HoHsi: посмотрите видяшку и успокойтесь. Там дядя боб рассказывает историю становления архитектуры ПО и аджайлов, как все пошло не так и т.д. Я думаю вам будет полезно.
HoHsi: я честно не видел на гитхабе ни одного приложения, ни на одном языке программирования (если не брать штуки типа postgresql), к коду которого стоит стремиться... все велосипеды, стэш и т.д. Лучшее что есть - отдельные библиотеки из которых строятся фреймворки. В JS мире красивого кода вообще малова-то.
copal: да насмотрелся дядю Боба (и вы посмотрите). Меня всегда смущало MVC в контексте WEB потому что... ну потому что ни о чем. Когда люди начинают трактовать такие примитивные и базовые вещи кто как захочет - значит что-то не так. Если даже почитать статьи что вы предлагали перевести - то там все очень даже просто. Есть ввод данных (controller), есть их вывод (view) и есть их обработка (model). Все. Причем никто и никогда в те времена не делал одну вьюху на скрин или один контроллер на скрин - все дробилось на элементы и для каждого была своя модель, свой контроллер, свое view. На фронтэнде, на UI, все к этому снова и идет (Angualr2, React), поток данных только в одну сторону (отказ от двустороннего датабиндинга, только односторонний), дробление UI на отдельные компоненты со своей моделью, контроллером и представлением. Маленькие масштабы, схема работы с данными, не архитектура.
Да даже если брать бэкэнд классический с html и т.д. тот самый HMVC конечно еще подходит (когда мы дробим UI на маленькие элементы для каждого из которого есть свои модели и свои контроллеры) но в случае с web api все чуть сложнее, так как тут дробить view не выйдет. У нас тупо сериализация данных, и все. То есть весь view сводится к мэппингу данных и сериализации. Ну и опять же это все только определяет как у нас разделено приложение и регламентирует направление потока данных (строго в одну сторону).
Словом MVC это не архитектура, это правило описывающее поток данных и разделение ответсвенности. CQRS чуть ближе походит на архитектуру, хотя опять же это несколько не то. Это абстрактное правило, бэст практис и только.
copal: вообще пишите в личку, мне было бы интересно этот вопрос обсудить с вами и придти наконец к какому-то разумному консенсусу. Но дядю боба (то что я в ответе привел) посмотрите.
Сергей Протько: возьмем скелет человека и разберем его по косточке. Каждая косточка это творение архитектора. то есть, это не просто объект, это совокупность объектов, которые складываются в некий механизм помогающий решать одну задачу. Косточка - шаблон проектирования
Теперь мы собираем все косточки вместе и получаем законченный скелет, который назовем mvc. Да, mvc - мульти-шаблон проектирования, совокупность шаблонов и точка, жирная точка.
Жирная по тому, что когда я создаю объект отображения и объект хранящий состояние этого объекта и реализующий его поведение, это не mvc, это просто два объекта, которые правильно спроектированы, раздроблены на части.
Теперь представим, что я не хочу писать все отдельные косточки каждый раз с самого начала. Я беру и создаю каждую косточку в виде библиотеки. Затем мне становится напряжно каждый раз складывать эти косточки в mvc, по этому я создаю чистый mvc framework. Архитектурный mvc фраймворк. А дальше мой фраймворк скачивают люди и кто-то на этот архитектурный скелет натягивает штаны, а кто-то юбку. Но каждый раз этот скелет остается все тем же mvc-человеческим скелетом, а не скелетом мамонта.
Если рассматривать создание современного сайта на примере HelloWord, то окажется что настоящая архитектура сайта будет отличаться от ранее продемонстрированной.
mvc нельзя рассматривать на примере кнопки. Кнопка это компонент, а архитектура для компонентов mvp. Точка.
На фронтэнде, на UI, все к этому снова и идет (Angualr2, React), поток данных только в одну сторону (отказ от двустороннего датабиндинга, только односторонний), дробление UI на отдельные компоненты со своей моделью, контроллером и представлением. Маленькие масштабы, схема работы с данными, не архитектура.
То что в современных фраймворках создают датабиндинг только в одну сторону,
означает лишь то, что они стремятся к настоящему mvc. Вам лучше смериться и признать что Вы как и многие другие были введены в заблуждение и сейчас видите не черти что, а то что должны были видеть с самого начала.
И Вы не поверите что настоящее mvc работает везде одинаково если ему там место.
А когда говорят что у каждого mvc свое или что на сервере или на клиенте не удается
реализовать одинаково, то это как религия. Когда буддист найдет на дороге мешок денег, он же не скажет что ему Иисус их дал. Каждый увидет то что он хочет видеть.
Словом MVC это не архитектура, это правило описывающее поток данных и разделение ответсвенности. CQRS чуть ближе походит на архитектуру, хотя опять же это несколько не то. Это абстрактное правило, бэст практис и только.
mvc, это как раз архитектура, которая не дает возможности сделать неправильно.
То есть Вам дан правильный стальной скелет, и то что Вы будите одевать его в костюм кролика не навредит здоровью самого организма-приложения.
mvc, это клей, который стопудово склеет части и наладит между ними правильную связь. Пусть Вы даже стремный код напишите, но правильный mvc фраймворк поможет создать работающие приложение.
Сергей Протько: в правильном mvc кнопка это представление. Для примера, представьте что вы пишите приложение кликер. Суть этого приложения считать число кликов, которые юзер сделал за минуту.
Логика-модель приложения, это время (минута), ведь изменение время изменит и само приложение, и число кликов по цели, это тоже модель, ведь если сделать число кликов не поцели, то суть приложения изменится.
Теперь я делаю представление поросенка. И начинаю играть в приложение. Через какое-то время мне надоело смотреть на поросенка и я добавил овечку. Изменилось приложение? Нет, значит овечка и поросенок отношение к модели не имеют.
О чем это говорит? О том, что js код, который заставляет бегать поросенка и js код который заставляет овечку прыгать, это представление.
Но что такое js код относительно поросенок.png? Это его модель, но не модель приложения. Видите грань, которая показывает mvc одного фигуранта триады и mvc архитектуру приложения. И если это понятно, то должно быть понятно и то, что mvc поросенка, это всего лишь компонент, который создан с разделением обязанностей с точки зрения mvc архитектуры.
Теперь представьте что экран, это mainview. Главное представление создает поросенка, который Вы теперь рассматриваете, как представление. То есть весь js код, это представление. После того, как Вы кликнете по поросенку, представление просит контроллер передать сообщение о клике модели. Без разницы, как это будет реализована, это может сделать косточка event или косточка databinding или signal. Дальше модель получает это уведомление и решает, ведь кому решать как не модели, ведь это она и есть само архитектурное приложение, записывать этот клик или нет. А то вдруг у нас будет ограничение по времени, нельзя стрелять в порося чаще одного раза в секунду. А кому ещё как не модели иметь таймеры отсчитывающие это время.
И вот значит клик защитан, а что дальше? А дальше будет то, что заложено в модель приложения, поросенок умирает. Модель не контроллер, а модель сообщает представлению, что поросенок умер.
А вот как это представление mvc приложения сделает, уже модель не касается.
И отдельное большое НО! когда я говорил что js код поросенка это модель, это не так. Если удобно написать по принципу зазделения, то пожалуйста. Но чаще бывает так, что тот же чекбокс это просто состояние. То есть js реализует состояние, но при этом этот код не является моделью приложения чекбокс. Почему не является? по тому что тут вообще нет контроллера. Контроллер нужен будет только в архитектуре mvc. То есть подписывая в js кнопку мы не создаем контроллер, это всего лишь внутренние события представления...
я написал целую гору писанины но решил удалить... вместо этого сокращу до следующих пунктов:
- уговорили, MVC это GUI архитектура и точка, это не архитектура всего приложения, более того к самому приложению это никакого отношения может не иметь.
- пример с кнопкой - я не так пожалуй выразился. Имелось в виду что для кнопки можно сделать отдельный контроллер который будет говорить модели что надо делать. Кнопка ничего не знает о представлении или может быть частью одного из представлений модели или его части.
- фреймворк не скелет приложения, это не его опора. Это второстепенная фигня, набор готовых решений часто встречающихся проблем, набор абстракций и только. Наше приложение не должно зависить от него, наоборот, мы должны выстроить между фреймворком и приложением стену. Но не надо понимать это как призыв к отказу от фреймворков - наоборот, надо знать их место. Это просто инструменты.
- на бэкэнде нет места классическому MVC так как это GUI архитектура. Ему есть место только в контексте реализации UI-layer приложения.
Пусть Вы даже стремный код напишите, но правильный mvc фраймворк поможет создать работающие приложение.
copal:
в правильном mvc кнопка это представление.
в правильном MVC кнопка это кнопка. Она может не быть частью представления модели, это может быть просто кнопка, механизм ввода. Пользователь тыкает на кнопку, контроллер обрабатывает клик и говорит модели что делать. Причем кнопка ничего не знает о модели, а модель ничего не знает о том кто попросил и каким способом сделать то что оно сделало.
Пример с поросенком и овечкой не показательный, у меня по нему не выходит проследить ваш поток мыслей.
Короче пока я только убедился в том что я правильно понимаю концепцию MVC, так как вы говорите о том же о чем и я, вот только у меня фокус не на MVC, в моем мире MVC это GUI архитектура, а GUI отделено от приложения, от бизнес логики, это всего лишь ввод/вывод информации. Подумайте над этой проблемой в контексте CLI, попробуйте применить MVC к CLI скриптам. Или например MVC к обработчикам MQ. У вас получится что-то неповоротливое и большое.
И еще я понял что в вашем представлении есть такие вещи как MVC фреймворки (мне не понятно что это такое, MVC фреймворк, как по мне это все маркетинговый булшит, если мы говорим про бэкэнд), я еще понимаю MVC библиотека для более удобной организации компонентов UI, такие как React или тот же Angular2, но опять же, это отдельные библиотеки. И фреймворк в моем представлении это только набор библиотек и не более. Слой абстракций. Фреймворк удобен только тогда когда его компоненты можно заменять в случае ситуации которую не покрывает этот фреймворк.
словом из ваших комментариев пока у меня складывается впечатление что у нас выходит некое недопонимание. Я погорячился когда сказал что MVC это не архитектура, но это не архитектура самого приложения. В целом саму концепцию мы воспринимаем одинаково, но у вас слишком часто проскакивают "фреймворки" и прочая чушь. Я не знаю как вы это связываете вместе, более того я считаю что вы считаете фреймворки краеугольным камнем, фундаментом приложения. Я же считаю что приложение должно быть полностью изолировано от фреймворка, предоставляя интерфейсы, которые реализуются с применением компонентов фреймворка.
Продолжение в личку. Мне реально интересно разобраться.
Сергей Протько: не думаю чтобы кто-то был против обсуждения.
Вы считает что фраймворки это набор библиотек, а это так и есть, но не хотите понять, что mvc это принцип по которым эти библиотеки связываются. mvc, это теория рассказывающая, как должны связываться части приложения. Я ещё раз употреблю слово "клей", так как именно это mvc и делает. То есть я написал независимый модуль и сделал его моделью, так же я сделал независимый модуль представления. И вот теперь сам фраймворк должен связывать работу модели и представления. Другое дело что тот же angular это не делает, но он мне кажется и не скрывает того, что убогий.
Наше приложение не должно зависить от него, наоборот
Тут я полностью согласен, но я и не говорю об архитектуре, которая убога как например в angular. Ведь я не могу написать представление, которое будет работать без ангулар, так как там обращаешься через element. Вот это жесткая связанность, а не клей.
Клей был бы, да и должен быть в виде представлений, которые просто медиаторы. То есть фраймворк не должен представлять для представления ничего, кроме медиаторов, которые должны на уровне фраймворка связываться с бэйс моделями, которые связанны агрегацией с нашими настоящими независимыми моделями.
Приблизительно такая архитектура вообще бы не обременяла наш код.
И при этом оно было бы ограничивало Ваши действия вгоняя в нужное русло, ведь оно бы реализовывало и модели и представления и контроллеры в своих недрах.
Это было бы как в сказке - положи в ящик батарейки (модель), в другой лампочку(представление) и получил из третьего фонарик.
это теория рассказывающая, как должны связываться части приложения.
Не части нашего приложения, а части отдельного компонента UI (не кнопка конечно, но скажем форма редактирования чего-то).
Давайте все же определимся. Помниться месяц-два назад вы мне скидывали ссылки на оригинальные статьи/сканы переписок/публикации 79-ого года о MVC. Вопрос был в том что бы это дело перевести и опубликовать (я к слову сегодня всерьез задумался об этом). Я их даже почитал, особенно ту часть которая описывает что такое модель, что такое контроллер и что такое view.
Так вот, мы все еще говорим о том самом MVC которому уже 35 лет? Точно? Потому что мне как-то кажется что нет.
Давайте так, на бэкэнде нет MVC потому что:
- нет обзервабл связей между моделью и представлением
- контроллер как правило знает о представлении (чего он знать не должен, его задача простая - обработать ввод данных пользователя)
- модель, согласно документам 79-ого года, должна быть либо одним объетом, либо структурой, объедененной ассоциацией один-к-одному (то бишь дерево). И все было бы хорошо если бы мы делали aggregate root или что-то в этом духе, хранили бизнес логику в сущностях и пихали их во view. Тогда правила бы сохранялись.
- одна модель (или его часть) должна иметь одно или больше представлений.
Что же мы видим в типичном RoR приложении и приложениях на RoR-like фреймворках? В тех самых "правильных" MVC фреймворках? Люди пихают несколько моделей в одну view, у нас как правило одна жирная view на всю страницу! То есть один view для всех моделей задействованных для отрисовки одной страницы!
Вы видите разницу? На фронтэнде с этим проще, там UI дробится на компоненты, как правило у каждой модели есть маленькое view и маленький контроллер, контроллер ничего не знает о view, view связано с моделью обзервабл связью... то есть все как в той доке которая была опубликована 35 лет назад! И самое забавное что пришли к этому относительно недавно, а некоторые еще идут.
но я и не говорю об архитектуре, которая убога как например в angular
У ангуляра (если мы берем версию 1.4+) все относительно неплохо с архитектурой. При использовании компонентного подхода, при дроблении UI на директивы, каждая директива становится маленьким MVC приложением. То есть это именно то что нужно. Да, React в этом плане более правильный, так как он позволяет меньше непотребств. Благо в angular2 все с архитектурой хорошо и почти все что позволяло сделать плохо выпилили.
А вот если мы возьмем скажем RoR... что нам дает RoR? возможность организовать DAO + HTTP/CLI интерфейс. И все. Больше ничего. Все остальное - good old plain ruby, наше приложение. Никакого MVC внутри (у нас там нет ни представлений ни контроллеров). И это не модель в контексте MVC. Это штука которая возвращает модель по требованию. Возможно это будет "модель" в контексте active-record, а не православный transfer object. Возможно мы даже уподобимся сделать aggragate root и вернуть только ее а не пачку каких-то моделей, но что-то я сомневаюсь.
Если MVC это клей, то почему спустя 35 лет люди продолжают писать бизнес логику в контроллере? Может быть... люди слишком долго нюхают этот клей?
Дядя боб рассказывает про MVC и встречу в Осло с автором этой "архитектуры": видео. Посмотрите, там буквально пару минут.
Короче мое ИМХО:
- MVC это GUI архитектура, которая применима только для организации GUI. Для всего остального есть другие вещи. А на бэкэнде вместо контроллера в контексте MVC обычно используется GRASP-ский контроллер, задача которого транслировать асинхронные запросы пользователей в синхронные запросы к системе.
Считать что MVC это клей который связывает все это глупо. Нельзя описать "все" тремя компонентами с двумя стрелочками.
copal: еще у меня есть такая забавная мысль, что весь наш спор и выеденного яйца не стоит. MVC было придумано 35 лет назад с учетом тех реалий. Напомню, примерно в то время эпл и майрософт повзаимствовала у ксерокс все их наработки. С тех пор появилась куча адаптаций MVC под современные реалии усложщяющихся интерфейсов и больших объемов данных с которыми приходится работать. во фронтэнде сейчас доминирует HMVC а не чистый MVC. Да и на сервере. А тот MVC который придуман 35 лет назад... ну он дал основную идею, а дальше - развитие.
Короче принципы SOLID как по мне намного важнее чем загоны аля "MVC это или не MVC". Сейчас это не архитектура приложения, это архитектура UI максимум. Архитектура самого приложения имеет слой абстракций что бы полностью изолироваться от интерфейса, при помощи которого мы работаем с приложением. И это главное, абстракция. Что бы можно было изолировать основную часть нашего приложения, бизнес логику, бизнес правила, бизнес объекты. Что бы контроллеры оставались тонкими, что бы view layer вообще ничего не знал о наших бизнес объектах, пусть transfer object-ы кушает.
HoHsi: да никак, мы просто общаемся на тему MVC-фреймворков. В кратце, товарисч copal очень любит MVC а я считаю название MVC-фреймворк маркетинговым булшитом.
Так вот, мы все еще говорим о том самом MVC которому уже 35 лет? Точно? Потому что мне как-то кажется что нет.
Да, я об самом первом mvc. И именно с него, чтобы проследить по времени, как люди ошибаясь меняли его и называли "тем самым первым". М не встречались даже русские статьи на php, которые говорили неправильную трактовку, но ссылались на первоисточник.
- нет обзервабл связей между моделью и представлением
Ну первое что пришло в голову, онлайн векторина. Много пользователей смотрят на крутящиеся колесо и все видят одно и тоже, ведь модель на сервере рассылает сообщения представлениям, чтобы они обновлялись. И да, это на форму не распространяется, но и подтверждает что это исключение, так как я могу целую тучу таких примеров привести. Но! Пишу эти слова уже после того, как написал следующий абзац . Так как состояние рулетки это логика приложения, то с сервера-"настоящей модели" эти данные будут поступать в клиентскую модель. И вот тут есть расхождение. Если у Вас модель на клиенте общается с серверной моделью через контроллер, то правы Вы, если модели общаются напрямую, как если бы они не знали о том, что находятся очень деле друг от друга, то Вы не правы.
- контроллер как правило знает о представлении (чего он знать не должен, его задача простая - обработать ввод данных пользователя)
Ну вот Вы, насколько мне не изменяет память, не видите смысл в grid при верстке.
А я наоборот их люблю. Это я к тому, что если Вы даете возможность контроллеру делать больше чем нужно, то оно так и будет. Тем не мение проблема намного глубже.
Вот я например понимаю, что контроллер не должен быть вообще хоть на капельку разумным, но чтобы меня не считали еретиком, вынужден писать в вэб (для других) именно так, как это принято в вэб.
- модель, согласно документам 79-ого года, должна быть либо одним объетом, либо структурой, объедененной ассоциацией один-к-одному (то бишь дерево).
Так оно так и должно быть. Должна быть mainview, mainmodel,maincontrollr и да, они должны быть в виде дерева.
Считать что MVC это клей который связывает все это глупо. Нельзя описать "все" тремя компонентами с двумя стрелочками.
Вы то входите в калию, то Вас из неё выкидывает. модель находится на сервере. Сервер равно модель. Клиент это представление. Модель на клиенте, это интерфейс модели, которая на сервере. вы же наверняка слышали о том что программировать нужно на имплементациях. Вот этот тот самый случай. Почему говорят, что модель шлет событие и нужное и нужные представления лезут и берут отмеренные для них данные у модели. Вот если бы представление лезло на сервер, то оно бы лезло в объект модели. А так представление работает с интерфейсом.
А я вот считаю, что все наработки, которые есть сейчас были уже тогда, но только вот ими не делились. И я не считаю что это спор, для меня это способ подтверждения того, что я прав)))
И именно с него, чтобы проследить по времени, как люди ошибаясь меняли его
Если мы посмотрим на схему самого первого MVC то мы можем заметить, что сейчас повсеместно используется HMVC а не MVC.
ведь модель на сервере
сервер отдельно, клиент отдельно. Сервер не модель, модель это что-то маленькое, простая структура. Повторюсь, вы точно читали первоисточник?
В вашей аналогии с рулеткой сервер это база данных, приложению на клиенте глубоко плевать есть там сервер или нет, все может быть и без сервера, просто на клиенте, суть от этого не меняется.
Ну вот Вы, насколько мне не изменяет память, не видите смысл в grid при верстке.
Я не "не вижу смысла в grid при верстке", вы вырвали фразу из контекста. Я отвечал на вопрос "зачем нужны отдельные элементы? Можно же просто сделать универсальные элементы которые будут заточены под сетку". И ответ мой был к тому что не всегда сетка помогает. Я использую сетку, это довольно удобная штука, но это не панацея.
вынужден писать в вэб (для других) именно так, как это принято в вэб.
в web толстый контроллер считается плохой практикой, если что. То что вы делаете толстые контроллеры - это ваша личная проблема а не индустрии. У меня вот контроллеры обладают ограниченной ответственностью. Если мы берем сервер - то это перевод запроса из HTTP формата в формат приложение, скармливание этого дела сервису и формирование ответа из DTO пришедшего к нам из сервиса. В упрощенном случае это три строчки - десериализовать реквест, отправить в сервис, сериализовать респонс. Если мы говорим о клиенте - то задача контроллера - среагировать на действие пользователя и попросить модель/сервис что-то сделать с данными. И все. Контроллер на клиенте у меня ничегошеньки не знает о view и он весьма тонкий, вся логика вынесена в сервисы (angular).
они должны быть в виде дерева
Что именно в виде дерева? MVC 79-ого года подразумевает что у вас есть модель как структура данных, объект смолтоковский, возможно это какое-то дерево объектов. Контроллер - всегда один объект, представление - так же один объект, который может оперировать другими, но он один.
То что вы описываете - это HMVC а не MVC 79-ого года.
модель находится на сервере.
повторюсь но все же... сервер это не модель. А если и так то это только подтверждает что на самом сервере нет MVC, так как... ну это же модель....
Сергей Протько: Я читал (как мог с гугл переводчиком) вот о такой реализации, но она же и объясняется.
В вашей аналогии с рулеткой сервер это база данных, приложению на клиенте глубоко плевать есть там сервер или нет, все может быть и без сервера, просто на клиенте, суть от этого не меняется.
Нет. У меня на сервере запущен код-логика, которая эмитирует вращающую рулетку.
И каждый тик, она рассылает события моделям на клиенте. То есть, серверная модель не знает куда они диспатчит события, это не её дело. Её дело это работать. Модель из mvc должна быть работоспособной без других участников (представления и контроллера). Модель как душа, она должна "работать" всегда и ей без разницы надели на неё тело крокодила или виннипуха. Помните раньше были кресты для елок, которые крутили елки. Вот это модель. И вставь туда черенок от лопаты или тубу или вообще ничего не вставлять, она все равно будет работать.
Вам нужно понять что mvc это не клиент и сервер, это архитектура. В рамках mvc база данных ничем не отличается от обычного ассоциативного массива. Модель это модуль, который инкапсулировал в себе весь код, без которого наше приложение будет либо представлением либо контроллером либо и тем и другим одновременно.
Вот это модель из mvc.
Контроллер на клиенте у меня ничегошеньки не знает о view и он весьма тонкий, вся логика вынесена в сервисы (angular).
Это звучит как - "я перестал выкидывать мусор в форточку, выкидываю его за угол дома". Сервисы вообще не относятся к mvc. их и упоминать не стоит.
повторюсь но все же... сервер это не модель.
Куда Вы логику приложения засуните, то и модель. Я говорю о полноценной реализации логики. Не данных и не поведения.
Вот ответьте на вопрос - что клиентсерверном приложении поле чудес будет моделью? Что есть АРХИТЕКТУРНАЯ МОДЕЛЬ - ЛОГИКА ПРИЛОЖЕНИЯ и где она будет? "сорри за капс, я просто так словам значимости добавил"
отдельное внимание уделите словам UI architecture. Если интересно продолжить дискуссию - в личку. Тут я буду игнорировать уже, ибо мы уже достали окружающих)
Средний
Простой
