Здравствуйте, Other Sam, Вы писали:
Нет, мне однозначно нравится с вами общаться!
Вы хотя бы пытались
читать что я пишу?
OS>Я как знал, что не догоните!!!! ВНИМАТЕЛЬНО!!!! Смотрите на КАРТИНКУ в
OS>моем посте!!! (Это архитектура позволяющая строить огромные системы).
OS>ВНИМАТЕЛЬНО читайте комментарии
OS>// ---------- application layer
OS>// --------- UI layer ------
OS>Они не просто так! Они разъясняют архитектуру.
OS>Там еще есть комментарии. Из них вы поймете, что есть и другие способы
OS>организации UI layer (более подходящие, более ясные. Один из них XSLT).
Что такое слои я знаю. Зачем они нужны тоже.
Возможно вы сильно удивитесь, но контроллер (мы ведь с него начали, так?) относится к UI layer. Поэтому все остальные слои пустьостанутся за рамками нашей дискусии.
Ну и еще на заметку, раз вы не хотите ознакомится с ASP MVC: кроме кода контроллера в UI layer-е будет только вьюшка (Register.aspx), т.е. только разметка.
СУВ,
Aikin... << RSDN@Home 1.2.0 alpha 4 rev. 1466>>
> Нет, мне однозначно нравится с вами общаться!
> Вы хотя бы пытались *читать* что я пишу?
Да, хватит уже пытаться съязвить... В этом нет смысла.
> OS>Я как знал, что не догоните!!!! ВНИМАТЕЛЬНО!!!! Смотрите на КАРТИНКУ в
> OS>моем посте!!! (Это архитектура позволяющая строить огромные системы).
> OS>ВНИМАТЕЛЬНО читайте комментарии
> OS>// ---------- application layer
> OS>// --------- UI layer ------
> OS>Они не просто так! Они разъясняют архитектуру.
> OS>Там еще есть комментарии. Из них вы поймете, что есть и другие способы
> OS>организации UI layer (более подходящие, более ясные. Один из них XSLT).
> Что такое слои я знаю. Зачем они нужны тоже.
> Возможно вы сильно удивитесь, но контроллер (мы ведь с него начали,
> так?) относится к UI layer. Поэтому все остальные слои пустьостанутся за
> рамками нашей дискусии.
>
> Ну и еще на заметку, раз вы не хотите ознакомится с ASP MVC: кроме кода
> контроллера в UI layer-е будет только вьюшка (Register.aspx), т.е.
> только разметка.
Контроллер может относиться к UI (в глобальном плане) а может и не
относиться.
Но вот если аккуратненько вынуть часть системы учавствующую в одном
конкретном MVC и разместить ее по логическим уровням Layers, тогда
контроллер однозначно оказывается в Application Layer (выше модели, и
ниже вью).
Но это не важно. Какая разница где в Layers находится Контроллер, если в
рассматриваемой системе нет ни Layers ни Controller.
Каждую часть MVC тестировать легко и приятно.
На Layers приятно строить большие системы.
MVC (в том числе ASP MVC) — плохой выбор для ВЕБ.
Ваше нежелание тестировать свой код (который вы выше приводили), так и
осталось для меня иррациональным. Ваше нежелание выкинуть тот код — тоже
не понимаю. (Тестировать не хочу, т.к. код слишком жидкий и тесты будут
падать при каждом чихе, а выкинуть не хочу, просто потомучто).
--------
Кстати, в ветке design недавно было обсуждение MVC. И там тоже был
разброс в понимании деталей...
Я задумался, уж не я-ли туплю?!
Проверяю:
1. Русская вика:
http://ru.wikipedia.org/wiki/Model-View-Controller
"...Controller... ....и информирует модель и представление..."
(не верно)!
2. Нерусская вика:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
"The controller receives input and initiates a response by making
calls on model objects."
Мой перевод: Получателем входных воздействий является Контроллер. И он
же инициирует отклик системы путем обращения к объектам Моделям.
(верно)
"...controller accepts input... ...and instructs the model and
viewport..." (технически верно, но допускает некорректное толкование).
Обратите внимание указывается Viewport, а не View! Есть подозрение, что
это писал явьщик-свингист. Там вьюпорт — это UI контрол для аггрегации
вьюшек.
http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JViewport.html Если
посмотрим на него, то можно понять, что его можно "за уши" притянуть под
понятие Контроллер (методы setExtentSize, setViewSize,
scrollRectToVisible), а можно также притянуть за уши к понятию Модель
(getInsets, getView, addChangeListener, firePropertyChange...). В общем
в контексте обсуждения MVC зря упоминается столь сложный объект, да еще
и с именем похожим на View.
3. Еще в нерусской вике:
"The controller may (in some implementations) issue a general
instruction to the view to render itself. In others, the view is
automatically notified by the model of changes in state (Observer) which
require a screen update."
Мой перевод:
"В некоторых реализациях Контроллер может посылать общие команды во
вью, для отображения своего представления. В остальных реализациях
Вьюшки автоматически оповещаются моделью, обо всех изменениях
(Посредством событий) которые влекут перерисовку отображения".
(В целом близко к классике, но формулировки очень ненадежные).
Здесь, когда говорится о посылке событий из контроллера во вью, я думаю,
имеют ввиду объекты Action (Что-то близкое к шаблону проектирования
Комманда (Command)). Такие объекты Action сами уведомляют Вьюшки чтобы
например задизейблить кнопку, или пункт меню соответствующий этой
Action. В пользу моей догадки говорит то, что упоминается "general
instructions" (общие команды, общие для всех контроллеров комманды?).
4. Диаграммы в виках содержат ОЧЕНЬ неприятную неточность!!! Стрелочка
от Контроллека к вью! Ее быть не должно!!! Я решил поискать диаграмму
классов для этого шаблона у фаулера, однако набрел на
http://www.martinfowler.com/eaaDev/uiArchs.html
Он там сокрушается, что все по разному понимают MVC и предлагает свой
вариант, с разъяснениями. Так вот в подтверждение того, что стрелочки
быть не должно его слова "Controller and view should (mostly) not
communicate directly but through the model.". Перевожу: "Контроллеры и
Вью не должны взаимодействовать напрямую, а только через Модель (хотя
допускаются исключения)".
5. В конечном итоге я обратился к Trygve Reenskaug
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Там этот шаблон еще только зарождался, так что не очень-то понятно, но я
нашел
http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf
"MVC Pattern Language" Там в этом PDF на странице 14 приведены диаграммы
(уже почти UML), на которых видно, что контроллер не взаимодействует с
вью, а только с моделью.
В общем, если кто-то чувствует неуверенность в понимании MVC
ознакомьтесь с несколькими статьями (увы на английском), а также
посмотрите несколько реализаций (это должны быть GUI приложения, а не
Веб). Ну и знайте — в вике неточности.
Posted via RSDN NNTP Server 2.1 beta
Здравствуйте, Other Sam, Вы писали:
OS>Ваше нежелание тестировать свой код (который вы выше приводили), так и
OS>осталось для меня иррациональным.
Еще раз: он слишком прост, чтобы я в нем засомневался.
OS>Ваше нежелание выкинуть тот код — тоже не понимаю.
Не вижу альтернатив. То что вы привели раньше наоборот усложнение, а не упрощение.
OS>(Тестировать не хочу, т.к. код слишком жидкий и тесты будут
OS>падать при каждом чихе, а выкинуть не хочу, просто потомучто).
Этот код, скорее всего, вообще не будет изменятся в дальнейшем.
>> Нет, мне однозначно нравится с вами общаться!
>> Вы хотя бы пытались *читать* что я пишу?
OS>Да, хватит уже пытаться съязвить... В этом нет смысла.
Жаль.
OS>На Layers приятно строить большие системы.
Забудь про слои. Они здесь не в тему! Мы сейчас обсуждаем совсем другой вопрос.
OS>MVC (в том числе ASP MVC) — плохой выбор для ВЕБ.
А "мужики-то не знают! (с)" и написали целый
фреймворк, на которм написано много крупных вэб приложений. Например
Stack Overflow
OS>Кстати, в ветке design недавно было обсуждение MVC. И там тоже был
OS>разброс в понимании деталей...
OS>...
OS>В общем, если кто-то чувствует неуверенность в понимании MVC
OS>ознакомьтесь с несколькими статьями (увы на английском), а также
OS>посмотрите несколько реализаций (это должны быть GUI приложения, а не
OS>Веб). Ну и знайте — в вике неточности.
То что вариантов MVC вагон и маленькая тележка я в курсе.
Но дело в том, что я не рассматриваю архитектурный паттерн. Я говорю про
конкретную его реализацию в ASP MVC.
Мне не нужно его реализовывать, он уже реализован во фреймворке.
P.S. Не пишите, плиз, такие развернутые посты. Не тратьте свое время. Я вполне себе состоявшийся специалист и не только знаю о всем том, что вы
уже говорили, но и сложил свое мнение об этом.
СУВ,
Aikin... << RSDN@Home 1.2.0 alpha 4 rev. 1466>>
Здравствуйте, npe, Вы писали:
npe>Исходная ситуация: ...
Читая этот абзац, подумал: а не в одном ли мы проекте трудимся?
Очень знакомая ситуация.
3 года уже работаю в таком проекте (самому проекту уже 10 лет; где-то 1.5млн строчек кода; разработка будет вестись пока у продукта есть пользователи; одно слово — БАНК).
Придя и увидев, что инфраструктура юнит тестов скорее мертва, чем жива (в автоматический процесс сборки процедура запуска тестов не входит, а сами разработчики трогают имеющиеся тесты, только если они перестают собираться), я погоревал чуток и стал как все (и без тестов хватало поводов задуматься: а туда ли я пришёл работать куда хотел?).
Не так давно моя позиция изменилась.
Изменилась под влиянием:
— нового члена в команде (который, вдохнув в меня веру, сам её потерял и перестал быть членом команды
— и двух книг (почему-то мною пропущенных ранее):
— "Working Effectively with Legacy Code.chm"
— "Meszaros G. — xUnit Test Patterns. Refactoring Test Code(2007)(883).pdf"
Новичку дали задачу связанную с компонентом, который я годом ранее написал. Он обратился ко мне с вопросами и, слово за слово, стали писать тесты на новую функциональность. Первые же тесты показали пару проблем в старом коде: пусть не фатальных, но пропущенных и QA и на code review. Тогда я стал заново изучать литературу.
Первая книга показала, что legacy code таки можно взять за жабры и загнать под тесты.
Вторая — как правильно эти и другие тесты писать и как затем поддерживать.
Дао, оказалось, заключено в том, что тесты — это не тесты.
Написание тестов позволяет сократить время уходящее на кодирование, при сохранении качества кода (количества багов).
Как? Да очень просто:
— тесты позволяют спрашивать систему как она себя ведёт (когда кода МНОГО, а документации МАЛО — это очень экономит время)
— тесты избавляют от рутинных действий, что позволяет не терять внимание и экономить массу времени (типичная ситуация — не нужно запускать приложение и делать 25 мышекликательных движений, чтобы увидеть результаты своих изменений)
— тесты могут документировать требования по которым писался/пишется код (и плевать, что они его не тестируют даже на 20%!)
— тесты могут документировать API (на уровне достаточном для того, чтобы начать задавать правильные вопросы коду или коллегам)
— тесты выявляют опечатки в коде существенно быстрее, чем мозг.
Хочу отметить, что всё это можно получить без необходимости ставить раком всю команду (читать: убедить, что тесты писать надо и научить как это делать правильно).
Ставить раком нужно только если стоит цель повысить-таки качество кода и есть необходимые ресурсы (время, знания).
