Комментарии 45
У меня простой вопрос: а почему вы противопоставляете MVC и «компонентные решения»? Это, в общем-то, ортогональные вещи, можно иметь компоненты в MVC, можно писать не в MVC без компонентов.
Это не «проблема», это данность. Вы в вебе, он по природе своей stateless. Любые попытки это состояние ему придать — в той или иной форме «костыли».
А-га. Здравствуй, масштабируемость, возвращение через час и тому подобные милые вещи. А уж как это мило тестировать…
Одна из существенных проблем MVC, как и других некомпонентных решений, — отсутствие обеспечения персистентности (сохранения состояния элементов) страницы между вызовами с браузера. В старом добром WebForms мы ставили на форму, например, чекбокс и не волновались как он будет отрисован и как будет восстановлено его состояние после перезагрузки. [...] По сути то же, как в десктопе.
Это не «проблема», это данность. Вы в вебе, он по природе своей stateless. Любые попытки это состояние ему придать — в той или иной форме «костыли».
И при этом не нужен никакой ViewState — экземпляр класса страницы с дочерними компонентами и, соответственно, их данными, хранится в серверной сессии.
А-га. Здравствуй, масштабируемость, возвращение через час и тому подобные милые вещи. А уж как это мило тестировать…
У меня простой вопрос: а почему вы противопоставляете MVC и «компонентные решения»? Это, в общем-то, ортогональные вещи, можно иметь компоненты в MVC, можно писать не в MVC без компонентов.
MVC сам себя противопоставляет в вебе. Он просто неестественнен. Об этом, например, довольно доходчиво пишет Дмитрий Котеров в своей книге.
На самом деле компоненты уже реализуют принцип отделения логики от представления и (в данном случае) являются событийно ориентированными. MVC тут нечего добавить.
Это не «проблема», это данность. Вы в вебе, он по природе своей stateless. Любые попытки это состояние ему придать — в той или иной форме «костыли».
я ж не меняю протокол HTTP. Я делаю так чтобы с точки зрения програмиста была персистентность. То же самое делает WebForms — на нем разраб програмирует как на Делфи.
А-га. Здравствуй, масштабируемость, возвращение через час и тому подобные милые вещи. А уж как это мило тестировать
не очень понятно о чем вы. И какая проблема с тестированием напримрер тем же selenium. А компоненты масштабируемы по своей природе.
Еще раз -нет никаких проблем ни с масштабируемостью ни с чем то еще. Фремворк (PHP вариант, по крайней) уже обкатан, это не просто теория.
Я не говорю что это идеальное решение для всех случаев но для интерактивных сайтов где нужно постояное взаимодействия пользователя с интерфейсом (бизнес-приложения в первую очередь) не вижу ничего лучше. Лучше не моей реализации (можно взять тот же, более профессионально написаный Wicket ) — а в принцие самой архитектуры, самой идеи.
MVC сам себя противопоставляет в вебе.
Кому?
Он просто неестественнен.
А по-моему, та его вариация, которую предлагает asp.net, прекрасно ложится на работу http-сервера. Что неестественного?
я ж не меняю протокол HTTP. Я делаю так чтобы с точки зрения програмиста была персистентность.
… которой в протоколе нет. Это и есть костыль.
То же самое делает WebForms — на нем разраб програмирует как на Делфи.
Вот как раз это в вебе неестественно.
И какая проблема с тестированием напримрер тем же selenium.
Интерфейсным тестированием мир не ограничивается. Меня всегда больше интересует unit и прочие серверные вариации.
не очень понятно о чем вы.
О том, что сессия — это серверное хранилище. Серверное хранилище не позволяет вам сделать дешевую серверную ферму (горизонтальное масштабирование) — вам надо либо прилеплять сессии к конкретной машине, либо выносить их за пределы машины (а это означает, что появляются дополнительные накладные расходы). И это еще не считая проблем с уникальной идентификацией всех компонентов внутри сессии (а что, если я решил открыть два экземпляра одной страницы?).
А компоненты масштабируемы по своей природе.
Компоненты «по своей природе» ортогональны масштабируемости.
а в принцие самой архитектуры, самой идеи.
Чем ваша архитектура отличается от WebForms?
Изобрели свой ВебФормс)))
Кому?
здравому смыслу вообще и компонентам в частности
А по-моему, та его вариация, которую предлагает asp.net, прекрасно ложится на работу http-сервера. Что неестественного?
на работу сервера может быть -серверу все равно. А вот на работу програмиста — нет. Програмист должен заниматся имплементацией бизнес логики а не заботой о том как восстановить состояние страниы после перезагрузки.
которой в протоколе нет. Это и есть костыль.
в таком случае и сессионные хранилища предоставляемые вебсерверами -костыль
О том, что сессия — это серверное хранилище. Серверное хранилище не позволяет вам сделать дешевую серверную ферму (горизонтальное масштабирование) — вам надо либо прилеплять сессии к конкретной машине, либо выносить их за пределы машины (а это означает, что появляются дополнительные накладные расходы).
раскажите это J2EE серверам которые лихо масштабируются вместе со всеми сессиями. Чего кстати не делает и ваш драгоценный MVC.
Компоненты «по своей природе» ортогональны масштабируемости.
что именно там не масштабируется? Если уж вы такой фанат MVC то могу вас обрадовать — архитектура любого компонента и есть маленький MVC — там есть контроллер (обработчик событий) модель и представление. разница только в том что этот MVC не размазан по всему приложению.
И не пытайтесь меня сразить вумными конструкциями типа «ортогональны масштабированию». Я не начинающий разраб.
Чем ваша архитектура отличается от WebForms?
Прежде всего, устранением проблемы взаимодействия с HTML кодом (фронтэнд-разрабы которые работали с WebForms понимают о чем я). В остальном идея совпадает. Майкрософт устранил проблемы заменив технологию на черти что.
Я устранил взявши другую идею, которая сохраняет компонентный подход (служивший годами верой правдой — разработчики WebForms опять же понимают о чем я, начинающие, которые ничего не видели кроме MVC разумеется нет) но при этом представление полностью отделяется от серверной логики. Там нет никаких автоматически сгенеренных ID, никаких «птичьих» языков шаблонизаторов. Конечно пассивные шаблонизаторы тоже не идеальны. но нет в мире ничего идеального.
И вообще непонятна ваша болезненная реакция — боитесь что завтра ваш менеджер прочитавши статью уволит вас как больше ненужного MVC програмиста.
здравому смыслу вообще и компонентам в частности
Нет, MVC не противопоставляет себя компонентам. Собственно, вы сам позже пишете, что [ваше] компоненты внутри себя представляют маленький MVC.
Програмист должен заниматся имплементацией бизнес логики а не заботой о том как восстановить состояние страниы после перезагрузки.
Если вы абстрагируете программиста от естественных деталей протокола, для которого он пишет, вы делаете это ценой чего-то. Идеология asp.net MVC была в том, чтобы вернуть программиста ближе к протоколу, чтобы писать более естественные для окружения вещи.
в таком случае и сессионные хранилища предоставляемые вебсерверами -костыль
Так и есть.
раскажите это J2EE серверам которые лихо масштабируются вместе со всеми сессиями.
А чего там рассказывать, я даже понимаю, как это делается.
Чего кстати не делает и ваш драгоценный MVC.
Кстати, неправда. В MVC можно сделать оба описанных выше сценария.
что именно там не масштабируется?
А я вроде и не говорил, что что-то не масштабируется.
Прежде всего, устранением проблемы взаимодействия с HTML кодом (фронтэнд-разрабы которые работали с WebForms понимают о чем я).
Ага, а у вас html-код не меняется?
боитесь что завтра ваш менеджер прочитавши статью уволит вас как больше ненужного MVC програмиста.
Нет, не боюсь. Моя нынешняя работа вообще не связана с MVC.
Если вы абстрагируете программиста от естественных деталей протокола, для которого он пишет, вы делаете это ценой чего-то. Идеология asp.net MVC была в том, чтобы вернуть программиста ближе к протоколу, чтобы писать более естественные для окружения вещи.
Я считаю что задачf програмиста реализовывать бизнес логику, то есть практическую задачу. Вас не смущает что языки высокого уровня абстрагируют програмиста от функционирования процессора? Наверно есть ряд задач которые требуют работы с протоколом, но большинство задач требуют реализации бизнес-логики. Это и есть «естественныве вещи».
Ага, а у вас html-код не меняется?
Не меняется ничего что влияет на работу фронт-энд разраба.
Работа бэск-энда и работа фронтэнда, как вы изволили выразится — ортогональна.
Вас не смущает что языки высокого уровня абстрагируют програмиста от функционирования процессора?
Не смущает. Вопрос цены этой абстракции.
Наверно есть ряд задач которые требуют работы с протоколом, но большинство задач требуют реализации бизнес-логики.
Бизнес-логику надо реализовывать в бизнес-слое.
Не меняется ничего что влияет на работу фронт-энд разраба.
Кстати, интересно. А как у вас реализуется классическая задача «если выбран радио 1, показать вот эту группу, если выбран радио 2, показать вот эту группу»?
Работа бэск-энда и работа фронтэнда, как вы изволили выразится — ортогональна.
Вот если они несогласованы, мы получаем impedance mismatch, который постоянно приходится чем-то затыкать.
Не смущает. Вопрос цены этой абстракции.
что то мне подсказывает что писать на аcсемблере гораздо более хлопотно чем на C#.
Кстати, интересно. А как у вас реализуется классическая задача «если выбран радио 1, показать вот эту группу, если выбран радио 2, показать вот эту группу»?
как и в вебформс — выбрали радиокнопку сработало событие на сервере — для одной панели (сервер компонент Panel, клиент — div) вызвали setVisible(false) для другой setVisible(true)
Все.
что то мне подсказывает что писать на аcсемблере гораздо более хлопотно чем на C#.
… и тем не менее ассемблер не вымер.
сработало событие на сервере — для одной панели (сервер компонент Panel, клиент — div) вызвали setVisible(false) для другой setVisible(true)
Очень хорошо, и как эти
setVisible повлияли на html-код?и тем не менее ассемблер не вымер.
да, но использует в узком классе (или правилнее количестве) задач. Чего желаю и MVC
Очень хорошо, и как эти setVisible повлияли на html-код?
кэп подсказывает что будет показан тот или другой кусок HTML кода.
кэп подсказывает что будет показан тот или другой кусок HTML кода.
Что значит «будет показан»? В ответе HTTP-сервера будет либо один, либо другой фрагмент?
в данной реализации да
можно было бы конечно выставлять display:none но зачем гонять лишнее.
если у компонента стоит что он невидим шаблонизатор его просто проигнорирует.
В противном случае будет вызван метод render()
и компонент изменит соответствующий ему фронтэнд тэг.
можно было бы конечно выставлять display:none но зачем гонять лишнее.
если у компонента стоит что он невидим шаблонизатор его просто проигнорирует.
В противном случае будет вызван метод render()
и компонент изменит соответствующий ему фронтэнд тэг.
в данной реализации да
В этот момент у верстальщика взрывается мозг: он делал верстку с учетом двух дивов, а он стал один.
и компонент изменит соответствующий ему фронтэнд тэг.
И снова плач верстальщика: он написал одно, а в аут ушло другое.
В этот момент у верстальщика взрывается мозг: он делал верстку с учетом двух дивов, а он стал один.
пока ни разу не взорвался
верстальщик вообще то когда верстает имеет представление что он верстает и как оно работает.
а как по вашему работает интерфейс на каком нибудь ангуляре где виимость блока прибиндена к тем же радиокнопкам?
И снова плач верстальщика: он написал одно, а в аут ушло другое.
какое другое? Ушли данные а не изменилась верстка. Да текст в поле может оказаться разной длины но я не вижу как бывает по другому при других технологиях.
В итоге все сводится к очевидному: верстальщик должен быть знаком с технологией, под которую он верстает. И в этом смысле нет фундаментальной разницы, используете вы ваш подход, Razor, или что-то еще — все равно результирующий html-код будет отличаться от того, к чему привык верстальщик, и ему надо будет это учитывать.
В итоге все сводится к очевидному: верстальщик должен быть знаком с технологией, под которую он верстает.
Он должен быть знаком с поведением контента который он верстает.
И в этом смысле нет фундаментальной разницы, используете вы ваш подход, Razor,
Верстальщака интесует не фундаментальность а то что он видит.
Видит HTML тэг или неведомую конструкцию.
Видит HTML тэг
Угу, давайте посмотрим на конкретном примере.
Вот мы хотим компонент «грид». Стандартный компонент, в любом фреймворке неплохо бы иметь. Как он выглядит в html-коде в вашем случае? В том html-коде, который верстальщик пишет?
Наименование
Ед.изм.
Кол.
Цена
Ед.изм.
Кол.
Цена
<table class="ctable" >
<tr ><th >Наименование </th><th width="50">Ед.изм.</th><th width="40">Кол.</th> <th width="40">Цена</th> <th width="50"> </th>
</tr>
<tr zippy="detail">
<td zippy="item"></td>
<td zippy="measure"></td>
<td zippy="quantity" align="right"></td>
<td zippy="price" align="right"></td>
<td><a zippy="edit"><i class="icon-edit"></i> <a zippy="delete"><i class="icon-remove"></i></a> </td>
</tr>
</table>
не пойму как тут отформатировать
А сортировка? Фильтрация? Пейджинг? Раскраска зеброй? Инлайн-редактирование?
(отдельно большое вам спасибо за необходимость дважды определять колонку — сначала в заголовке, а потом в теле)
(отдельно большое вам спасибо за необходимость дважды определять колонку — сначала в заголовке, а потом в теле)
А сортировка?
как и в .NET MVC соответстующая ссылка в заголовок.
Фильтрация?
каким боком тут фильтрация?
Раскраска зеброй?
CSS3 — 21-ый век за окном
Пейджинг?
есть компонент который прописывается одной строкой кода.
На клиенте просто Все остальное автоматически — генерация страницы, обработка событий и вынимание сооьвеььсвующей порции данных из источникак данных для грида.
пример из PHP
$detailt = $this->add(new DataView('detail', new DocDataSource(), $this, 'doclistOnRow'));
$this->add(new Paginator('pag', $detailt));
. Это компоненты, сынок.
Инлайн-редактирование?
а что в MVC есть инлайн редактирование?
Впрочем, здесь я могу автоматически вывести таблицу в любыми инпутами и все они автоматически же отправятся на сервер.
(отдельно большое вам спасибо за необходимость дважды определять колонку — сначала в заголовке, а потом в теле)
Почему дважды? заголовок это верстка — там ничего не надо определять.
Кроме того для чисто текстовых жанных есть еще один компонент который автоматически
рендерит сортировку и пагинацию
как и в .NET MVC соответстующая ссылка в заголовок.
В html-коде это видно?
(и нет, «в asp.net mvc» это не так)
каким боком тут фильтрация?
Таким — хочу кликнуть на заголовке колонки и ввести фильтр.
есть компонент который прописывается одной строкой кода.
В html-коде это видно?
а что в MVC есть инлайн редактирование?
Для asp.net mvc, конечно же, есть компоненты, поддерживающие инлайн-редактирование в гридах.
Впрочем, здесь я могу автоматически вывести таблицу в любыми инпутами и все они автоматически же отправятся на сервер.
Как это выглядит в html-коде?
Почему дважды? заголовок это верстка — там ничего не надо определять.
Потому что колонка — это одна сущность, у которой есть название (заголовок) и привязка к данным. А в вашем коде название прописано отдельно, привязка к данным — отдельно. Ничего не стоит перепутать.
В html-коде это видно?
видно. куда оно денется
(и нет, «в asp.net mvc» это не так)
там вообще никак. Но это один из способов имплементации.
Таким — хочу кликнуть на заголовке колонки и ввести фильтр.
можно запрограмировать. Где это встроено в MVC?
Как это выглядит в html-коде?
древний пример для PHP версии
zippy.com.ua/index.php?p=/Pages/Examples/Example10
Для asp.net mvc, конечно же, есть компоненты, поддерживающие инлайн-редактирование в гридах.
Это, как и вышеуказаное, не относится к сути обсуждаемого архитектурного решения. Надо будет сяду и напишу такой компонент для своего фреймворка. С фильтрами блекджеком и юными пррамистками. Пока инлайн редактирование нафиг не нужно было ги в одном проекте…
А в вашем коде название прописано отдельно, привязка к данным — отдельно. Ничего не стоит перепутать.
С чего бы оно путалось? Табличные данные выводят сколько существует HTML — первый раз слышу о проблеме перепутывания заголовков и данных.
видно. куда оно денется
Вот, покажите. Меня, собственно, интересует html-код для нормальной полнофункциональной реализации грида (сортировка, фильтрация, инлайн-редактирование, пейджинг).
там вообще никак.
Это неправда.
Это, как и вышеуказаное, не относится к сути обсуждаемого архитектурного решения.
Относится-относится. Вы декларируете, что в вашем решении верстальщик имеет дело с обычным html-кодом. Вот я и хочу на это посмотреть.
С чего бы оно путалось?
С того, что люди ошибаются.
Это неправда.
Еще раз. Здесь обсуждается концепция. А вы мне расказываете о неких готовых решениях гридов и прочее.
У майкрософта сотни програмистов. Они понаписали компонентов. Я написал то что успел написать.
Как наличие того или иного компонента написаного в пределах концепции влияет на саму идею? Завтра напишут компонент с фильтрами и сортировками на перле для CGI и что это докажет?
Я вам показал простой грид где чистый HTML код и код который для Razor где вообще никакого HTML а непонятная верстальщику абракадабра где ему надо еще догадаться как добавить атрибут в тег. А вы продолжаете доказывать что верстальщику там проще.
В MVC програмиста волнует какой там будет заголовок а в моем решении нет. И не должно волновать — програмисту незачем заглядывать в PSD файл созданный дизайнером чтобы прописать заголовки в модели для грида. Вы считаете что должен? Тогда в чем смысл разделения кода от представления?
Вообще спор уже бессмысленный. Я не ставлю задачу когото переубедить.
. пишите как вам по кайфу.
Мне понравилась идея я ее реализовал попинал, понял что это есть хорошо и изложил это на бомаге. Удачи.
.
.
Относится-относится. Вы декларируете, что в вашем решении верстальщик имеет дело с обычным html-кодом. Вот я и хочу на это посмотреть.
я вм уже сто раз показал — это все чистый HTML
С того, что люди ошибаются.
А в MVC человек не может прописать не тоо название в атриуте модели?
Как наличие того или иного компонента написаного в пределах концепции влияет на саму идею?
Так я не про наличие компонентов говорю, я хочу увидеть, как такой компонент выглядит в коде.
Я вам показал простой грид где чистый HTML код
Вы покажите пример этого же грида для описанной мной ситуации.
В MVC програмиста волнует какой там будет заголовок а в моем решении нет. И не должно волновать — програмисту незачем заглядывать в PSD файл созданный дизайнером чтобы прописать заголовки в модели для грида. Вы считаете что должен?
В любом LoB-приложении заголовки прописывает не дизайнер, а бизнес-аналитик. И они должны быть униформны по всей системе.
А в MVC человек не может прописать не тоо название в атриуте модели?
Может. Но вероятность этого ниже, потому что одно дело — следить за атрибутом на свойстве, а другое — сопоставлять порядок в двух разных списках.
О тестировании (и вообще о граблях):
/master/src/ZippyNet/Core/HttpRequest.cs
/master/src/ZippyNet/Core/Html/Form/TextInput.cs
(и так далее)
Вот в WebForms по этим граблям уже походили, поэтому в MVC сделали иначе, а в WebAPI и OWIN — ушли еще дальше от них. А вы продолжаете по ним прыгать.
/master/src/ZippyNet/Core/HttpRequest.cs
public class HttpRequest
{
//...
public HttpRequest()
{
this.uri = HttpContext.Current.Request.Url.Query;
//...
if (HttpContext.Current.Request.QueryString["q"] != null || HttpContext.Current.Request.Form["q"] != null)
{
//...
if (HttpContext.Current.Request.HttpMethod == "POST")
{
q = HttpContext.Current.Request.Form["q"];
}
else
{
q = HttpContext.Current.Request.QueryString["q"];
}
//...
}
if (HttpContext.Current.Request.QueryString["r"] != null)
{
//...
string r = HttpContext.Current.Request.QueryString["r"];
//...
object[] p = (object[])Newtonsoft.Json.JsonConvert.DeserializeObject(r);
//...
}
}
}
/master/src/ZippyNet/Core/Html/Form/TextInput.cs
public override void getRequestData()
{
this.setText(HttpContext.Current.Request.Form[this.id]);
}
(и так далее)
Вот в WebForms по этим граблям уже походили, поэтому в MVC сделали иначе, а в WebAPI и OWIN — ушли еще дальше от них. А вы продолжаете по ним прыгать.
нет там никаких граблей. Я не претендую на особое качество кода — моя задача была просто описать идею. Код можно совершенствовать.
Просто в данном случае нет смысла тестировать дергая экшены или API. Тут другая идеология. Вы как пользователь взаимодействуете с компонентами. и тестировать надо точно также. Как передать данные серверу и получить ответку задача компонента. Туда вообще незачем лазить — black box. Завтра протокол может быть переписан по человечески но это не отразится на работе существующего сайта — там компонент, как он передал данные как получил как себя отрендерил никак не влияет на бизнес логику и взаимодействие с клиентом.
Что касается вышеназваных технолий — они ушли чтобы устранить проблемы MVC а не WebForms.
Зачем мне WebApi если у меня просто сайт, как в большинстве случаев, и нет необходимости взаимодействовать в с внешними сервисами.
Использовать это чтобы взаимодействовать с клиентскими фреймворками — как минимум непродуктивно с точки зрения трудозатрат на разработку. В этом просто нет смысла если задача реализуется класическим способом.
Про грабли на мобильных браузерах (да и просто браузерах) от клиентских javascript фрейморков я уже упоминал.
Просто в данном случае нет смысла тестировать дергая экшены или API. Тут другая идеология. Вы как пользователь взаимодействуете с компонентами. и тестировать надо точно также. Как передать данные серверу и получить ответку задача компонента. Туда вообще незачем лазить — black box. Завтра протокол может быть переписан по человечески но это не отразится на работе существующего сайта — там компонент, как он передал данные как получил как себя отрендерил никак не влияет на бизнес логику и взаимодействие с клиентом.
Что касается вышеназваных технолий — они ушли чтобы устранить проблемы MVC а не WebForms.
Зачем мне WebApi если у меня просто сайт, как в большинстве случаев, и нет необходимости взаимодействовать в с внешними сервисами.
Использовать это чтобы взаимодействовать с клиентскими фреймворками — как минимум непродуктивно с точки зрения трудозатрат на разработку. В этом просто нет смысла если задача реализуется класическим способом.
Про грабли на мобильных браузерах (да и просто браузерах) от клиентских javascript фрейморков я уже упоминал.
Просто в данном случае нет смысла тестировать дергая экшены или API. Тут другая идеология.
Почему нет смысла? Нам же надо протестировать, что код, который реализует бизнес-логику, корректно передает данные в представление и получает их оттуда.
Что касается вышеназваных технолий — они ушли чтобы устранить проблемы MVC
Нет, просто они развивали начатые в asp.net MVC архитектурные принципы.
Почему нет смысла? Нам же надо протестировать, что код, который реализует бизнес-логику, корректно передает данные в представление и получает их оттуда
Нет нам надо протестировать что приложение работает корректно.
К примеру, есть компонент — ссылка по которой сервак должен ответить «Hello, dude!»
Вот и тестируйте что если кликнуть по компоненту (с помощью selenium или там Codeception) вас поприветствут. А как тестировать сами компоненты — это уже задача их разработчика Не вы их пишете не вам и тестировать — тестируйте свой сайт. А если кривой компонент то тут то же самое если кривая реализация .NET MVC фреймворка или AngularJs — вопрос к производителю оного..
Именно в этом одна из фишек компонентов — масштабируемость разработки.
Нет, просто они развивали начатые в asp.net MVC архитектурные принципы..
Это дипломатичный способ сказать — устраняли косяки :).
Нет нам надо протестировать что приложение работает корректно.
Это слишком общая задача.
Не вы их пишете не вам и тестировать — тестируйте свой сайт
Вот я и хочу протестировать, что когда компонент мне сказал «по мне кликнули», пошел вызов в бизнес-слой «пришел пользователь и кликнул», а ответ бизнес-слоя завернули в компонент. И следующим тестом — что когда в бизнес-слое вызвали «пришел пользователь и кликнул», тот вернул «Hello, dude!». Unit-тестирование во всей его красе.
Это дипломатичный способ сказать — устраняли косяки
С этой точки зрения, любое развитие ПО — устранение косяков.
Это слишком общая задача.
это главная задача нет никаких причин придумывать еще какие то.
Unit-тестирование во всей его красе.
зачем вам эта краса? У вас приложение — вы тестируете его бизнес логику. Какое вам дело что происходит в каких то слоях. Точнее у вас один слой — слой бизнес логики.
На сервере — это просто функция — обработчик события которая реализует логику. В данному случае Вызвать что то типа LabelHello.setText(«Hello dude»);
Одна строка кода. Никаких model которые чем то заполнить потом куда то передать, да еще и указать какой view
просто ( код абстрактно)
function linkDudeOnClick(Sender){
LabelHello.setText(«Hello dude»);
}
в статье более полный пример.
вот этот ваш код вы и тестируете. Остальное забота компонентов
— их достаточно оттестировать один раз и это забота их разраба.
Юнит тесты надо гонять там где програмист кроме бизнес логики програмирует еще кучу всего связанного с инфраструктурой а не полезным кодом. — как том же MVC. И в каждом новом сайте опять програмирует то же самое а значит надо опять тестировать.
.
С этой точки зрения, любое развитие ПО — устранение косяков.
вот я и устраняю только другим способом
Удивляюсь как все эти новомодные тренды, всякие TDD и прочие изобретения кибинетных теоретиков перекручивают людям мозги.
это главная задача нет никаких причин придумывать еще какие то.
Эту задачу необходимо разумным образом декомпоновать, иначе она в голову не влезает.
зачем вам эта краса?
Чтобы тестировать один кусочек за раз.
У вас приложение — вы тестируете его бизнес логику.
Именно. Я хочу тестировать бизнес-логику, а не интерфейс. А вы предлагаете мне тестировать интерфейс.
Точнее у вас один слой — слой бизнес логики.
А как же разделение на представление и бизнес-логику? Пропало?
В данному случае Вызвать что то типа LabelHello.setText(«Hello dude»);
Одна строка кода. Никаких model которые чем то заполнить потом куда то передать, да еще и указать какой view
Да нет, просто у вас модель выродилась в одну строчку, которую вы собственно и передаете в представление через метод
setText.function linkDudeOnClick(Sender){ LabelHello.setText(«Hello dude»); }
вот этот ваш код вы и тестируете.
Я правильно понял, что вы это называете бизнес-логикой и бизнес-слоем?
Юнит тесты надо гонять там где програмист кроме бизнес логики програмирует еще кучу всего связанного с инфраструктурой
А бизнес-логику юнит-тестами покрывать не надо?
вот я и устраняю только другим способом
Ну, в вашем конкретном случае вы возвращаетесь к тем проблемам, которые были в WebForms, причем были давно.
Удивляюсь как все эти новомодные тренды, всякие TDD
Очень новомодные, ага. TDD меньше, чем на год моложе, чем asp.net (это если от книжки Бека считать, на самом деле — старше).
Эту задачу необходимо разумным образом декомпоновать, иначе она в голову не влезает.
Ну если в голову влезает реализация проекта то как то уже место для тестирования того что уже и так в голове должно быть.
Чтобы тестировать один кусочек за раз.
зачем? вы пользователю отдаете проект или его кусочки?
Именно. Я хочу тестировать бизнес-логику, а не интерфейс. А вы предлагаете мне тестировать интерфейс.
нет. вы тестируете бизнес логику с помощью интерфейса. Того самого которым пользуется конечный юзер.
вы сели в автомоиль и едете — проверяете как он едет. можно конечно полезть в двигатель но зачем если он нормально едет.
А как же разделение на представление и бизнес-логику? Пропало?
как раз бизнес-логика отделена от представления максимально насколько это возможно.
Да нет, просто у вас модель выродилась в одну строчку
это потому что оперируете категориями MVC.
модель — это по сути то где хранятся данные и где им манипулируют. как правил персистентное хранилище. Это класическое понятие модели. оддель не передается скопом в представление.
Я правильно понял, что вы это называете бизнес-логикой и бизнес-слоем?
да. Это то что делает приложение с прикладной точки зрения. не больше и не меньше.
А бизнес-логику юнит-тестами покрывать не надо?
ну считайте что проверка этого конкретного клика и есть юнит тест.
Юнит тест именно бизнес логики а не компонента.
Ну, в вашем конкретном случае вы возвращаетесь к тем проблемам, которые были в WebForms, причем были давно.
в таком случае я просто использовал бы WebForms. именно устранение тих проблем и есть смысл данной поделки. просто погулите изначальные проблемы webForms именно то что свзано с предсталением.
Очень новомодные, ага. TDD меньше, чем на год моложе, чем asp.net (это если от книжки Бека считать, на самом деле — старше)
я имел ввиду модные сейчас. Наконецто удалось распиарить.
Лет 15 назад был моден RUP(Rational unified proces) теперь Agile. Что изменилось по сути в програмировании? Да ничего. Потому все это уйдет в небытие и вынут что то новое, новые теории организации проектов, тестирования и т.д. Только производительность труда, то есть достижение конечного результата от этого мало меняется. Тогда рисовали в UML теперь сидим на скрамах.
Ну если в голову влезает реализация проекта
Так не влезает же.
зачем?
Чтобы получать точную диагностику, где и что сломалось.
можно конечно полезть в двигатель но зачем если он нормально едет.
А если не едет — где искать, в двигателе, в КПП, еще где-то?
как раз бизнес-логика отделена от представления максимально насколько это возможно.
Значит, не один слой.
модель — это по сути то где хранятся данные и где им манипулируют. как правил персистентное хранилище. Это класическое понятие модели.
Вы, конечно, можете указать авторитетный источник для этого «классического понятия»?
да. Это то что делает приложение с прикладной точки зрения. не больше и не меньше.
… и этот бизнес-слой размещен напрямую в коде, отвечающем за представление, прямо в обработчике UI-события. Здравствуй, прекрасный мир WebForms. Спасибо, нет, никогда больше.
ну считайте что проверка этого конкретного клика и есть юнит тест.
Так как мне его проверить, не трогая слой представления?
именно устранение тих проблем и есть смысл данной поделки.
Проблема в том, что вы унаследовали кучу проблем WebForms, которые сейчас сохранять… стыдно.
Лет 15 назад был моден RUP(Rational unified proces) теперь Agile. Что изменилось по сути в програмировании? Да ничего.
А, если для вас за последние 15 лет в программировании ничего по сути не изменилось, тогда понятно, почему у вас код такой, как писали 15 лет назад.
Только производительность труда, то есть достижение конечного результата от этого мало меняется.
Странно, а я вижу, как меняется.
Так не влезает же
потому что запииваете туда много лишнего не относящегося к сути дела.
Чтобы получать точную диагностику, где и что сломалось.
а если сломалось в сетевой карте?
А если не едет — где искать, в двигателе, в КПП, еще где-то?
искать ближайшую СТО и дать возможность специалистам по компонентам(двигателям и пр.) занятся своим делам.
… и этот бизнес-слой размещен напрямую в коде, отвечающем за представление, прямо в обработчике UI-события. Здравствуй, прекрасный мир WebForms. Спасибо, нет, никогда больше.
За представление отвечает компонент.
Так как мне его проверить, не трогая слой представления?
вы его не трогаете.
Даже не знаю как обьяснить. Нет никакого слоя представления в привычном вам понимании.
Каждый компонент сам отвечает за свой рендеринг. Общий layout то есть куда какой компонент разместить — это задача верстальщика он просто работает с HTML тэгами. Некоторые из них являются фронт-эндом компонентов но верстальщику это по боку. В вебформс было не совсем по боку. Вот эта проблема и устранена.
Проблема в том, что вы унаследовали кучу проблем WebForms, которые сейчас сохранять… стыдно.
я бы конечно покраснел но не пойму за что
.А, если для вас за последние 15 лет в программировании ничего по сути не изменилось, тогда понятно, почему у вас код такой, как писали 15 лет назад.
код как код. я не говорю что он красивый моя задача реализовать идею в свободное время. Потому и опенсорс. Кому надо шашечки а не ехать — пул реквесты никто не отменял.
а что такого появилось в КОДЕ за эти 15 лет? Особое форматирование?
Странно, а я вижу, как меняется.
конечно но не по вышеуказаным причинам. У меня поменялся когда я делаю проект на своем велосипеде. А о верстальщике который видит только HTML а не, прости Господи, Html.TextBoxFor(m => m.from, new { class = «form-control date» }) даже не говорю
потому что запииваете туда много лишнего не относящегося к сути дела.
Нет, потому что сложность проекта больше, чем может съесть один человек.
а если сломалось в сетевой карте?
То я этого в юнит-тесте не увижу никогда, и слава б-гу.
За представление отвечает компонент.
… и страница, которая их объявляет. Разве нет?
Вот этот код — это представление:
public class MainPage : ZippyNet.Html.WebPage
{
public MainPage ()
{
Label label1 = new Label("label1", "Hello");
ClickLink link1 = new ClickLink("link1");
//назначаем серверный обработчик
link1.setClickHandler((HtmlComponent sender) =>
{
label1.setText("I am clicked");
});
// добавляем элементы к классу страницы.
this.add(link1);
this.add(label1);
}
}
вы его не трогаете.
Как же не трогаю, когда в тестируемой функции явно сказано
LabelHello.setText("Hello dude")? Прямое обращение к представлению.Нет никакого слоя представления в привычном вам понимании.
Тогда как разделены представление и бизнес?
я бы конечно покраснел но не пойму за что
Это было видно еще по вашей реакции на ваш же код.
Кому надо шашечки а не ехать — пул реквесты никто не отменял.
А смысл, если я могу взять работающий и решающий мои задачи asp.net MVC?
а что такого появилось в КОДЕ за эти 15 лет?
C#, например. И посмотрите, какой путь он проделал: дженерики, лямбды, LINQ, динамики.
конечно но не по вышеуказаным причинам.
А по каким же?
Нет, потому что сложность проекта больше, чем может съесть один человек.
ну так ешьте командой.
То я этого в юнит-тесте не увижу никогда, и слава б-гу.вы ввобше ничего не увидите и ваш юнит тест будет нае намного полезнее комлексного. Отсюда вопрос а на фига он.
Прямое обращение к представлению.
обращение к компоненту. Или по вашему промежуточная структура в виде модели (а точнее не модели а DTO) в MVC меняет суть дела и вы там не обращаетесь к представлению?
считайте что компонент такой же промежуточный слой.
А смысл, если я могу взять работающий и решающий мои задачи asp.net MVC?
WebForms тоже решал ваши задачи. Более того старый добрый CGI тоже.
C#, например. И посмотрите, какой путь он проделал: дженерики, лямбды, LINQ, динамики.
я имел ввиду код а не язык. Если вы имеете ввиду что все эти шняги нужно юзать то я не против.
В данном случае я не хотел чтобы код сильно отличался от PHP прототипа. Меньше писать коментов, проще искать ошибки, и все такое. Потому просто переложил с учетом другого синтаксиса.
Да и какая разница как я там написал. Речь о сути идеи и ломке стереотипов. забудьте вы мой код как страшный сон.
ну так ешьте командой.
А чтобы есть командой, надо побить на кусочки. А кусочки, в свою очередь, хочется тестировать вне зависимости друг от друга.
вы ввобше ничего не увидите
Почему? Юнит-тесту не нужная сетевая карта для работы.
обращение к компоненту.
А компонент — не часть представления разве?
Или по вашему промежуточная структура в виде модели (а точнее не модели а DTO) в MVC меняет суть дела и вы там не обращаетесь к представлению?
Во-первых, не DTO, а ViewModel. А во-вторых — меняет. В asp.net MVC я не обращаюсь к представлению, я возвращаю данные, которые использует представление. Inversion of control.
WebForms тоже решал ваши задачи. Более того старый добрый CGI тоже.
asp.net MVC решает их лучше.
я имел ввиду код а не язык.
А язык определяет код, который на нем написан. Появился новый язык — изменился код.
Речь о сути идеи и ломке стереотипов.
Да какая ломка стереотипов, если ваш код не рассматривать, то все ваше предложение сводится к asp.net WebForms с другим шаблонизатором и viewstate в сессии.
А чтобы есть командой, надо побить на кусочки. А кусочки, в свою очередь, хочется тестировать вне зависимости друг от друга.
они и так независимы. тестируете реакцию одного линка потом другого.
Почему? Юнит-тесту не нужная сетевая карта для работы.Никакому не нужна если на локале. Всем нужно если нет.
Во-первых, не DTO, а ViewModel. А во-вторых — меняет. В asp.net MVC я не обращаюсь к представлению, я возвращаю данные, которые использует представление. Inversion of
control.
Это именно DTO как бы вы его не называли. Присваиваете данные некоей структуре и отправляете ее менять представление. Как шаблонизатор использует данную структуру сути дела не меняет. Там Inversion of
control у меня DOM модель.
asp.net MVC решает их лучше.
с точки зрения фаната MVC — да.
На работе я програмирую и на WebForms и на MVC — мое решение лучше этого. Все относительно. По крайней мере я могу сравнивать на практике свсе три подхода а просто теоретизировать.
А язык определяет код, который на нем написан. Появился новый язык — изменился код.
смотря что писать. 2+2=4 ybrfr yt vtyztncz jn yfdjhjxtyjcnb zpsrf/
то все ваше предложение сводится к asp.net WebForms с другим шаблонизатором и viewstate в сессии.
viewstate там ни причем.
мое предложение сводится к использованию компонентного подхода вместо дебильного MVC.
они и так независимы. тестируете реакцию одного линка потом другого.
… и если ни один не работает, я не знаю — ошибка в самих линках или в бизнес-логике. А еще бывают, внезапно, совместно используемые бизнес-объекты.
Никакому не нужна если на локале. Всем нужно если нет.
Да нет же. Юнит-тест гоняется в памяти машины, ему никогда не нужна сеть (разве что результаты куда-то запостить).
Присваиваете данные некоей структуре и отправляете ее менять представление. Как шаблонизатор использует данную структуру сути дела не меняет.
Есть фундаментальная разница между «я явно вызвал слой представления и передал ему данные» и «я вернул данные, которые потом будут использованы слоем представления». Второе намного легче тестировать (да и представление подменять тоже).
с точки зрения фаната MVC — да.
С точки зрения моего личного опыта. Я семь лет писал на WebForms, потом пять лет на MVC — и после WebForms писать на MVC было намного проще.
viewstate там ни причем.
Угу, а состояние компонентов у вас нигде не хранится?
мое предложение сводится к использованию компонентного подхода вместо дебильного MVC.
Во-первых, если вы не можете что-то понять и применить, это еще не делает его дебильным. Во-вторых, в MVC прекрасно можно использовать компоненты, так что «вместо» здесь неприменимо.
… и если ни один не работает, я не знаю — ошибка в самих линках или в бизнес-логике.
ошибка в бизнес логике. В самих линках это когда вы дергаете экген а контроллер не реагирует. и ка тут поможет югит тестинг.
А еще бывают, внезапно, совместно используемые бизнес-объекты.
и какие проблемы?
Я семь лет писал на WebForms, потом пять лет на MVC — и после WebForms писать на MVC было намного проще.а я сделал чтобы было ее проще.
Есть фундаментальная разница между «я явно вызвал слой представления и передал ему данные»
это словоблудие. я не вызываю никакой слой представления.
Я передаю данные компоненту. Там может быть мильен всякизх слоев а может быть ни одного.
компонент например может ответить аяксом.
Суть компонентов чтобы программист не пудрил себе и другим мозги всякими слоями.
Во-первых, если вы не можете что-то понять и применить, это еще не делает его дебильным
Именно потому что применяю и вижу что оно дебильное.
я трачу намного больше времени чем в WebForms. хотя бы для реализации персистентности.
Во-вторых, в MVC прекрасно можно использовать компоненты, так что «вместо» здесь неприменимо.
там где компоненты MVC нечего делать.
У меня есть компонент — он реагирует на клиентское событие серверным обработчиком. Шо тут делать MVC?
Ну запихните MVC в WebForms или наоборот если не понимаете о чем речь.
.
В самих линках это когда вы дергаете экген а контроллер не реагирует. и ка тут поможет югит тестинг.
Юнит-тесты помогут тем, что я просто не буду взаимодействовать с линками, а буду взаимодействовать прямо с бизнес-логикой.
и какие проблемы?
Никаких. Просто их лучше тестировать отдельно.
а я сделал чтобы было ее проще.
Это так не выглядит.
это словоблудие. я не вызываю никакой слой представления. Я передаю данные компоненту.
Компонент — это и есть слой представления.
Суть компонентов чтобы программист не пудрил себе и другим мозги всякими слоями.
Вы считаете, что слои не нужны?
Именно потому что применяю и вижу что оно дебильное.
Вы уверены, что проблема в asp.net MVC, а не в вас?
я трачу намного больше времени чем в WebForms. хотя бы для реализации персистентности.
А я — меньше (потому что у меня есть маппер из вью-моделей в персистентные модели, а дальше все делает ORM).
Но вы, наверное, хотели сказать, что вы тратите больше времени на то, чтобы сохранить состояние страницы. Странно, но опять-таки, я его трачу меньше (точнее, я трачу меньше времени на то, чтобы понять, что и почему viewstate передает таким или другим образом, и в каком порядке оно инициализируется).
там где компоненты MVC нечего делать.
Почему?
У меня есть компонент — он реагирует на клиентское событие серверным обработчиком. Шо тут делать MVC?
Вызвать серверный обработчик в рамках контроллера, в чем проблема-то?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Альтернатива .NET MVC и WEB Forms