потому что запииваете туда много лишнего не относящегося к сути дела.
Чтобы получать точную диагностику, где и что сломалось.
а если сломалось в сетевой карте?
А если не едет — где искать, в двигателе, в КПП, еще где-то?
искать ближайшую СТО и дать возможность специалистам по компонентам(двигателям и пр.) занятся своим делам.
… и этот бизнес-слой размещен напрямую в коде, отвечающем за представление, прямо в обработчике UI-события. Здравствуй, прекрасный мир WebForms. Спасибо, нет, никогда больше.
За представление отвечает компонент.
Так как мне его проверить, не трогая слой представления?
вы его не трогаете.
Даже не знаю как обьяснить. Нет никакого слоя представления в привычном вам понимании.
Каждый компонент сам отвечает за свой рендеринг. Общий layout то есть куда какой компонент разместить — это задача верстальщика он просто работает с HTML тэгами. Некоторые из них являются фронт-эндом компонентов но верстальщику это по боку. В вебформс было не совсем по боку. Вот эта проблема и устранена.
Проблема в том, что вы унаследовали кучу проблем WebForms, которые сейчас сохранять… стыдно.
я бы конечно покраснел но не пойму за что
.А, если для вас за последние 15 лет в программировании ничего по сути не изменилось, тогда понятно, почему у вас код такой, как писали 15 лет назад.
код как код. я не говорю что он красивый моя задача реализовать идею в свободное время. Потому и опенсорс. Кому надо шашечки а не ехать — пул реквесты никто не отменял.
а что такого появилось в КОДЕ за эти 15 лет? Особое форматирование?
Странно, а я вижу, как меняется.
конечно но не по вышеуказаным причинам. У меня поменялся когда я делаю проект на своем велосипеде. А о верстальщике который видит только HTML а не, прости Господи, Html.TextBoxFor(m => m.from, new { class = «form-control date» }) даже не говорю
Эту задачу необходимо разумным образом декомпоновать, иначе она в голову не влезает.
Ну если в голову влезает реализация проекта то как то уже место для тестирования того что уже и так в голове должно быть.
Чтобы тестировать один кусочек за раз.
зачем? вы пользователю отдаете проект или его кусочки?
Именно. Я хочу тестировать бизнес-логику, а не интерфейс. А вы предлагаете мне тестировать интерфейс.
нет. вы тестируете бизнес логику с помощью интерфейса. Того самого которым пользуется конечный юзер.
вы сели в автомоиль и едете — проверяете как он едет. можно конечно полезть в двигатель но зачем если он нормально едет.
А как же разделение на представление и бизнес-логику? Пропало?
как раз бизнес-логика отделена от представления максимально насколько это возможно.
Да нет, просто у вас модель выродилась в одну строчку
это потому что оперируете категориями MVC.
модель — это по сути то где хранятся данные и где им манипулируют. как правил персистентное хранилище. Это класическое понятие модели. оддель не передается скопом в представление.
Я правильно понял, что вы это называете бизнес-логикой и бизнес-слоем?
да. Это то что делает приложение с прикладной точки зрения. не больше и не меньше.
А бизнес-логику юнит-тестами покрывать не надо?
ну считайте что проверка этого конкретного клика и есть юнит тест.
Юнит тест именно бизнес логики а не компонента.
Ну, в вашем конкретном случае вы возвращаетесь к тем проблемам, которые были в WebForms, причем были давно.
в таком случае я просто использовал бы WebForms. именно устранение тих проблем и есть смысл данной поделки. просто погулите изначальные проблемы webForms именно то что свзано с предсталением.
Очень новомодные, ага. TDD меньше, чем на год моложе, чем asp.net (это если от книжки Бека считать, на самом деле — старше)
я имел ввиду модные сейчас. Наконецто удалось распиарить.
Лет 15 назад был моден RUP(Rational unified proces) теперь Agile. Что изменилось по сути в програмировании? Да ничего. Потому все это уйдет в небытие и вынут что то новое, новые теории организации проектов, тестирования и т.д. Только производительность труда, то есть достижение конечного результата от этого мало меняется. Тогда рисовали в UML теперь сидим на скрамах.
это главная задача нет никаких причин придумывать еще какие то.
Unit-тестирование во всей его красе.
зачем вам эта краса? У вас приложение — вы тестируете его бизнес логику. Какое вам дело что происходит в каких то слоях. Точнее у вас один слой — слой бизнес логики.
На сервере — это просто функция — обработчик события которая реализует логику. В данному случае Вызвать что то типа LabelHello.setText(«Hello dude»);
Одна строка кода. Никаких model которые чем то заполнить потом куда то передать, да еще и указать какой view
просто ( код абстрактно)
function linkDudeOnClick(Sender){
LabelHello.setText(«Hello dude»);
}
в статье более полный пример.
вот этот ваш код вы и тестируете. Остальное забота компонентов
— их достаточно оттестировать один раз и это забота их разраба.
Юнит тесты надо гонять там где програмист кроме бизнес логики програмирует еще кучу всего связанного с инфраструктурой а не полезным кодом. — как том же MVC. И в каждом новом сайте опять програмирует то же самое а значит надо опять тестировать.
.
С этой точки зрения, любое развитие ПО — устранение косяков.
вот я и устраняю только другим способом
Удивляюсь как все эти новомодные тренды, всякие TDD и прочие изобретения кибинетных теоретиков перекручивают людям мозги.
что то мне подсказывает что писать на аcсемблере гораздо более хлопотно чем на C#.
Кстати, интересно. А как у вас реализуется классическая задача «если выбран радио 1, показать вот эту группу, если выбран радио 2, показать вот эту группу»?
как и в вебформс — выбрали радиокнопку сработало событие на сервере — для одной панели (сервер компонент Panel, клиент — div) вызвали setVisible(false) для другой setVisible(true)
Все.
Почему нет смысла? Нам же надо протестировать, что код, который реализует бизнес-логику, корректно передает данные в представление и получает их оттуда
Нет нам надо протестировать что приложение работает корректно.
К примеру, есть компонент — ссылка по которой сервак должен ответить «Hello, dude!»
Вот и тестируйте что если кликнуть по компоненту (с помощью selenium или там Codeception) вас поприветствут. А как тестировать сами компоненты — это уже задача их разработчика Не вы их пишете не вам и тестировать — тестируйте свой сайт. А если кривой компонент то тут то же самое если кривая реализация .NET MVC фреймворка или AngularJs — вопрос к производителю оного..
Именно в этом одна из фишек компонентов — масштабируемость разработки.
Нет, просто они развивали начатые в asp.net MVC архитектурные принципы..
Это дипломатичный способ сказать — устраняли косяки :).
Если вы абстрагируете программиста от естественных деталей протокола, для которого он пишет, вы делаете это ценой чего-то. Идеология asp.net MVC была в том, чтобы вернуть программиста ближе к протоколу, чтобы писать более естественные для окружения вещи.
Я считаю что задачf програмиста реализовывать бизнес логику, то есть практическую задачу. Вас не смущает что языки высокого уровня абстрагируют програмиста от функционирования процессора? Наверно есть ряд задач которые требуют работы с протоколом, но большинство задач требуют реализации бизнес-логики. Это и есть «естественныве вещи».
Ага, а у вас html-код не меняется?
Не меняется ничего что влияет на работу фронт-энд разраба.
Работа бэск-энда и работа фронтэнда, как вы изволили выразится — ортогональна.
нет там никаких граблей. Я не претендую на особое качество кода — моя задача была просто описать идею. Код можно совершенствовать.
Просто в данном случае нет смысла тестировать дергая экшены или API. Тут другая идеология. Вы как пользователь взаимодействуете с компонентами. и тестировать надо точно также. Как передать данные серверу и получить ответку задача компонента. Туда вообще незачем лазить — black box. Завтра протокол может быть переписан по человечески но это не отразится на работе существующего сайта — там компонент, как он передал данные как получил как себя отрендерил никак не влияет на бизнес логику и взаимодействие с клиентом.
Что касается вышеназваных технолий — они ушли чтобы устранить проблемы MVC а не WebForms.
Зачем мне WebApi если у меня просто сайт, как в большинстве случаев, и нет необходимости взаимодействовать в с внешними сервисами.
Использовать это чтобы взаимодействовать с клиентскими фреймворками — как минимум непродуктивно с точки зрения трудозатрат на разработку. В этом просто нет смысла если задача реализуется класическим способом.
Про грабли на мобильных браузерах (да и просто браузерах) от клиентских javascript фрейморков я уже упоминал.
нет. Переделал вебформс для удобоваримого употребления. Да и идея не моя — я не такой продвинутый. Просто незакомплексованый — у меня за многолетний опыт програмирования уже имунитет на очередные модные фишки. Потому смотрю обьективно что есть хорошо а что есть от лукавого.
А по-моему, та его вариация, которую предлагает asp.net, прекрасно ложится на работу http-сервера. Что неестественного?
на работу сервера может быть -серверу все равно. А вот на работу програмиста — нет. Програмист должен заниматся имплементацией бизнес логики а не заботой о том как восстановить состояние страниы после перезагрузки.
которой в протоколе нет. Это и есть костыль.
в таком случае и сессионные хранилища предоставляемые вебсерверами -костыль
О том, что сессия — это серверное хранилище. Серверное хранилище не позволяет вам сделать дешевую серверную ферму (горизонтальное масштабирование) — вам надо либо прилеплять сессии к конкретной машине, либо выносить их за пределы машины (а это означает, что появляются дополнительные накладные расходы).
раскажите это J2EE серверам которые лихо масштабируются вместе со всеми сессиями. Чего кстати не делает и ваш драгоценный MVC.
Компоненты «по своей природе» ортогональны масштабируемости.
что именно там не масштабируется? Если уж вы такой фанат MVC то могу вас обрадовать — архитектура любого компонента и есть маленький MVC — там есть контроллер (обработчик событий) модель и представление. разница только в том что этот MVC не размазан по всему приложению.
И не пытайтесь меня сразить вумными конструкциями типа «ортогональны масштабированию». Я не начинающий разраб.
Чем ваша архитектура отличается от WebForms?
Прежде всего, устранением проблемы взаимодействия с HTML кодом (фронтэнд-разрабы которые работали с WebForms понимают о чем я). В остальном идея совпадает. Майкрософт устранил проблемы заменив технологию на черти что.
Я устранил взявши другую идею, которая сохраняет компонентный подход (служивший годами верой правдой — разработчики WebForms опять же понимают о чем я, начинающие, которые ничего не видели кроме MVC разумеется нет) но при этом представление полностью отделяется от серверной логики. Там нет никаких автоматически сгенеренных ID, никаких «птичьих» языков шаблонизаторов. Конечно пассивные шаблонизаторы тоже не идеальны. но нет в мире ничего идеального.
И вообще непонятна ваша болезненная реакция — боитесь что завтра ваш менеджер прочитавши статью уволит вас как больше ненужного MVC програмиста.
У меня простой вопрос: а почему вы противопоставляете MVC и «компонентные решения»? Это, в общем-то, ортогональные вещи, можно иметь компоненты в MVC, можно писать не в MVC без компонентов.
MVC сам себя противопоставляет в вебе. Он просто неестественнен. Об этом, например, довольно доходчиво пишет Дмитрий Котеров в своей книге.
На самом деле компоненты уже реализуют принцип отделения логики от представления и (в данном случае) являются событийно ориентированными. MVC тут нечего добавить.
Это не «проблема», это данность. Вы в вебе, он по природе своей stateless. Любые попытки это состояние ему придать — в той или иной форме «костыли».
я ж не меняю протокол HTTP. Я делаю так чтобы с точки зрения програмиста была персистентность. То же самое делает WebForms — на нем разраб програмирует как на Делфи.
А-га. Здравствуй, масштабируемость, возвращение через час и тому подобные милые вещи. А уж как это мило тестировать
не очень понятно о чем вы. И какая проблема с тестированием напримрер тем же selenium. А компоненты масштабируемы по своей природе.
Еще раз -нет никаких проблем ни с масштабируемостью ни с чем то еще. Фремворк (PHP вариант, по крайней) уже обкатан, это не просто теория.
Я не говорю что это идеальное решение для всех случаев но для интерактивных сайтов где нужно постояное взаимодействия пользователя с интерфейсом (бизнес-приложения в первую очередь) не вижу ничего лучше. Лучше не моей реализации (можно взять тот же, более профессионально написаный Wicket ) — а в принцие самой архитектуры, самой идеи.
потому что запииваете туда много лишнего не относящегося к сути дела.
а если сломалось в сетевой карте?
За представление отвечает компонент.
вы его не трогаете.
Даже не знаю как обьяснить. Нет никакого слоя представления в привычном вам понимании.
Каждый компонент сам отвечает за свой рендеринг. Общий layout то есть куда какой компонент разместить — это задача верстальщика он просто работает с HTML тэгами. Некоторые из них являются фронт-эндом компонентов но верстальщику это по боку. В вебформс было не совсем по боку. Вот эта проблема и устранена.
я бы конечно покраснел но не пойму за что
код как код. я не говорю что он красивый моя задача реализовать идею в свободное время. Потому и опенсорс. Кому надо шашечки а не ехать — пул реквесты никто не отменял.
а что такого появилось в КОДЕ за эти 15 лет? Особое форматирование?
конечно но не по вышеуказаным причинам. У меня поменялся когда я делаю проект на своем велосипеде. А о верстальщике который видит только HTML а не, прости Господи, Html.TextBoxFor(m => m.from, new { class = «form-control date» }) даже не говорю
да, но использует в узком классе (или правилнее количестве) задач. Чего желаю и MVC
кэп подсказывает что будет показан тот или другой кусок HTML кода.
Ну если в голову влезает реализация проекта то как то уже место для тестирования того что уже и так в голове должно быть.
зачем? вы пользователю отдаете проект или его кусочки?
нет. вы тестируете бизнес логику с помощью интерфейса. Того самого которым пользуется конечный юзер.
вы сели в автомоиль и едете — проверяете как он едет. можно конечно полезть в двигатель но зачем если он нормально едет.
как раз бизнес-логика отделена от представления максимально насколько это возможно.
это потому что оперируете категориями MVC.
модель — это по сути то где хранятся данные и где им манипулируют. как правил персистентное хранилище. Это класическое понятие модели. оддель не передается скопом в представление.
да. Это то что делает приложение с прикладной точки зрения. не больше и не меньше.
ну считайте что проверка этого конкретного клика и есть юнит тест.
Юнит тест именно бизнес логики а не компонента.
в таком случае я просто использовал бы WebForms. именно устранение тих проблем и есть смысл данной поделки. просто погулите изначальные проблемы webForms именно то что свзано с предсталением.
я имел ввиду модные сейчас. Наконецто удалось распиарить.
Лет 15 назад был моден RUP(Rational unified proces) теперь Agile. Что изменилось по сути в програмировании? Да ничего. Потому все это уйдет в небытие и вынут что то новое, новые теории организации проектов, тестирования и т.д. Только производительность труда, то есть достижение конечного результата от этого мало меняется. Тогда рисовали в UML теперь сидим на скрамах.
это главная задача нет никаких причин придумывать еще какие то.
зачем вам эта краса? У вас приложение — вы тестируете его бизнес логику. Какое вам дело что происходит в каких то слоях. Точнее у вас один слой — слой бизнес логики.
На сервере — это просто функция — обработчик события которая реализует логику. В данному случае Вызвать что то типа LabelHello.setText(«Hello dude»);
Одна строка кода. Никаких model которые чем то заполнить потом куда то передать, да еще и указать какой view
просто ( код абстрактно)
function linkDudeOnClick(Sender){
LabelHello.setText(«Hello dude»);
}
в статье более полный пример.
вот этот ваш код вы и тестируете. Остальное забота компонентов
— их достаточно оттестировать один раз и это забота их разраба.
Юнит тесты надо гонять там где програмист кроме бизнес логики програмирует еще кучу всего связанного с инфраструктурой а не полезным кодом. — как том же MVC. И в каждом новом сайте опять програмирует то же самое а значит надо опять тестировать.
.
вот я и устраняю только другим способом
Удивляюсь как все эти новомодные тренды, всякие TDD и прочие изобретения кибинетных теоретиков перекручивают людям мозги.
что то мне подсказывает что писать на аcсемблере гораздо более хлопотно чем на C#.
как и в вебформс — выбрали радиокнопку сработало событие на сервере — для одной панели (сервер компонент Panel, клиент — div) вызвали setVisible(false) для другой setVisible(true)
Все.
Нет нам надо протестировать что приложение работает корректно.
К примеру, есть компонент — ссылка по которой сервак должен ответить «Hello, dude!»
Вот и тестируйте что если кликнуть по компоненту (с помощью selenium или там Codeception) вас поприветствут. А как тестировать сами компоненты — это уже задача их разработчика Не вы их пишете не вам и тестировать — тестируйте свой сайт. А если кривой компонент то тут то же самое если кривая реализация .NET MVC фреймворка или AngularJs — вопрос к производителю оного..
Именно в этом одна из фишек компонентов — масштабируемость разработки.
Это дипломатичный способ сказать — устраняли косяки :).
Я считаю что задачf програмиста реализовывать бизнес логику, то есть практическую задачу. Вас не смущает что языки высокого уровня абстрагируют програмиста от функционирования процессора? Наверно есть ряд задач которые требуют работы с протоколом, но большинство задач требуют реализации бизнес-логики. Это и есть «естественныве вещи».
Не меняется ничего что влияет на работу фронт-энд разраба.
Работа бэск-энда и работа фронтэнда, как вы изволили выразится — ортогональна.
Просто в данном случае нет смысла тестировать дергая экшены или API. Тут другая идеология. Вы как пользователь взаимодействуете с компонентами. и тестировать надо точно также. Как передать данные серверу и получить ответку задача компонента. Туда вообще незачем лазить — black box. Завтра протокол может быть переписан по человечески но это не отразится на работе существующего сайта — там компонент, как он передал данные как получил как себя отрендерил никак не влияет на бизнес логику и взаимодействие с клиентом.
Что касается вышеназваных технолий — они ушли чтобы устранить проблемы MVC а не WebForms.
Зачем мне WebApi если у меня просто сайт, как в большинстве случаев, и нет необходимости взаимодействовать в с внешними сервисами.
Использовать это чтобы взаимодействовать с клиентскими фреймворками — как минимум непродуктивно с точки зрения трудозатрат на разработку. В этом просто нет смысла если задача реализуется класическим способом.
Про грабли на мобильных браузерах (да и просто браузерах) от клиентских javascript фрейморков я уже упоминал.
здравому смыслу вообще и компонентам в частности
на работу сервера может быть -серверу все равно. А вот на работу програмиста — нет. Програмист должен заниматся имплементацией бизнес логики а не заботой о том как восстановить состояние страниы после перезагрузки.
в таком случае и сессионные хранилища предоставляемые вебсерверами -костыль
раскажите это J2EE серверам которые лихо масштабируются вместе со всеми сессиями. Чего кстати не делает и ваш драгоценный MVC.
что именно там не масштабируется? Если уж вы такой фанат MVC то могу вас обрадовать — архитектура любого компонента и есть маленький MVC — там есть контроллер (обработчик событий) модель и представление. разница только в том что этот MVC не размазан по всему приложению.
И не пытайтесь меня сразить вумными конструкциями типа «ортогональны масштабированию». Я не начинающий разраб.
Прежде всего, устранением проблемы взаимодействия с HTML кодом (фронтэнд-разрабы которые работали с WebForms понимают о чем я). В остальном идея совпадает. Майкрософт устранил проблемы заменив технологию на черти что.
Я устранил взявши другую идею, которая сохраняет компонентный подход (служивший годами верой правдой — разработчики WebForms опять же понимают о чем я, начинающие, которые ничего не видели кроме MVC разумеется нет) но при этом представление полностью отделяется от серверной логики. Там нет никаких автоматически сгенеренных ID, никаких «птичьих» языков шаблонизаторов. Конечно пассивные шаблонизаторы тоже не идеальны. но нет в мире ничего идеального.
И вообще непонятна ваша болезненная реакция — боитесь что завтра ваш менеджер прочитавши статью уволит вас как больше ненужного MVC програмиста.
MVC сам себя противопоставляет в вебе. Он просто неестественнен. Об этом, например, довольно доходчиво пишет Дмитрий Котеров в своей книге.
На самом деле компоненты уже реализуют принцип отделения логики от представления и (в данном случае) являются событийно ориентированными. MVC тут нечего добавить.
я ж не меняю протокол HTTP. Я делаю так чтобы с точки зрения програмиста была персистентность. То же самое делает WebForms — на нем разраб програмирует как на Делфи.
не очень понятно о чем вы. И какая проблема с тестированием напримрер тем же selenium. А компоненты масштабируемы по своей природе.
Еще раз -нет никаких проблем ни с масштабируемостью ни с чем то еще. Фремворк (PHP вариант, по крайней) уже обкатан, это не просто теория.
Я не говорю что это идеальное решение для всех случаев но для интерактивных сайтов где нужно постояное взаимодействия пользователя с интерфейсом (бизнес-приложения в первую очередь) не вижу ничего лучше. Лучше не моей реализации (можно взять тот же, более профессионально написаный Wicket ) — а в принцие самой архитектуры, самой идеи.