Максималист пишет:
> Теперь стоит задача, сделать Web(AJAX) клиента к этому приложению. Класс
> Controller-а переезжает на серверную сторону и начинает общаться с
> моделью через интерфейс IModel напрямую, без посредников.

Проблема вот тут. По сути вы добавляете лишний контроллер.

> Вариантов решения видится несколько.
> 5. Какие еще методы решения данной проблемы вы предложите?

Написать другой контроллер.
1. Пользователь жмет кнопку на View (в браузере)
2. Котроллер (на жабаскрипте) лезет в web-service асинхронно
3. Получает данные, отображает в браузере.

> Какой бы метод решения выбрали вы? И если не сложно, напишите, почему.

Я выбросил бы Controller с серверной стороны и покопался бы в аджаксе.
Потому как ему, по идее, пофиг куда лазить. Собственно, AJAX и есть ваш
Controller, писаный на жабаскрипте.

Здравствуйте, Максималист, Вы писали:

М>Здравствуйте, samius, Вы писали:

М>>>Я не понял, что вы не поняли
М>>>Клиент вызывает асинхронный метод прокси. Прокси шлет пакеты на сервер. Серверный транспорт, получив пакеты, вызывает синхронный метод модели. Модель возвращает результат. Сервер шлет пакеты клиенту. Прокси уведомляет через метод обратного вызова, что данные получены
S>>Все слишком сложно!
S>>Клиент вызывает асинхронный метод прокси, и ждет пока вызов этого метода не завершится. Я правильно понял? прокси шлет пакеты на сервер, сервер вызывает асинхронный метод модели и только после этого завершает асинхронный метод, сервер шлет пакеты, а прокси на стороне клиента их принимает и понимает что вызов асинхронного метода завершен. Только после этого клиент возвращается в луп сообщений и ждет обратного вызова от сервера, чтобы синхронно вызвать метод EndGetData у прокси, и опять все заново, только обратно с данными.

М>Нет, не правильно.
М>Клиент вызывает асинхронный метод прокси, прокси "посылает пакет" и возвращает управление, все, поток освобождается. Никто никого не ждет.
М>Сервер вызывает синхронный метод модели и отправляет результат клиенту. Когда дынные от сервера пришли на клиент, там поднимается поток в котором вызывается метод обратного вызова клиента.
М>По факту я использую прокси созданый Visual Studio для доступа к Web servic-у и предоставляемые им асинхронные методы.
А я грешным делом подумал, что прокси и асинхронные методы шлет на сервер для выполнения асинхронных методов же на серверной реализации IModel

М>надеюсь теперь сумел донести используемую модель, а то мы как-то все не поймем друг друга
да, теперь понял.
Все же я предлагаю убрать асинхронные методы из интерфейса модели.

Здравствуйте, Максималист, Вы писали:

М><skipped>
Знаешь что меня смутило и смущает? Интерфейс IModel. Если тебе понадобилось серьезно изменять интерфейс, значит что-то тут не так. А не так тут было вот что
1. В реальности у тебя нет честного асинхронного метода на сервере, более того, судя по архитектуре он там нафиг не нужен, и впихнут он был исключительно как костыль для клиента.
2. На клиенте у тебя в действительности реализован не прокси. Честный бы прокси переадресовывал асинхронный вызов в асинхронный, а синхронный в синхронный. А ты схитрил, и у тебя асинхронный переадресовывается в синхронный.

И смысл такого интерфейса? Если бы его не было, то принципиально ничего не изменилось. Интерфейс — это контракт, и проектировать его нужно так же ответственно, как ты подписываешь контракт в банке.
Если у тебя твоё UI требует асинхронности, то нафига костыль было пихать на сервер и размазывать его по всей архитектуре? Вот отсюда и проблема. Адаптер преобразующий синхронность/асинхронность нужно было делать где-то на уровне UI. Мне так кажется.
Поэтому решение твоей проблемы с архитектурной точки зренимя, как мне кажется, состоит в том, чтобы привести интерфейс к тому виду, в котором он должен был быть изначально — выкинуть асинхронность на сервере, ну или реализовать честную асинхронность. Ну а если архитектурная составляющая встает в противоречие с экономической, тогда делай как проще.

Здравствуйте, Максималист, Вы писали:

GIV>>Зло контроллер на JS или нет вопрос филосовский Только асинхронные запросы все равно слать будешь через XMLHttpRequest c его асинхронной моделью. Соответственно асинхронность на сервере тебе по прежнему не нужна. Считай что прокси, который работал на десктопном клиенте уже написан. Стоит только сделать удобную обвязку вокруг всего этого (либ на эту полно).

М>Зло или нет, вопрос действительно философский, а вот как unit test писать, вполне прикладной

Поиск по JavaSctipt Unit Tests, JsUnit и тому подобное ничего не дал?

GIV>>Если хочешь чтоб все было как в дескотопе — юзай GWT.
М>Я на Microsoft сижу Но вот в этом я с гуглем согласный

М>

М>http://code.google.com/intl/ru/webtoolkit/
М>90% времени уходит на обработку особенностей браузеров, а недостаточная универсальность JavaScript делает совместное использование, тестирование и повторное использование компонентов AJAX сложным и ненадежным. Это неправильно!

Та надо Силверлайт юзать.

Здравствуйте, Максималист, Вы писали:

Р>>Я выбросил бы Controller с серверной стороны и покопался бы в аджаксе.
Р>>Потому как ему, по идее, пофиг куда лазить. Собственно, AJAX и есть ваш
Р>>Controller, писаный на жабаскрипте.

М>Интересное мнение, спасибо.

М>Правда, я считаю, что Controller на JS это зло. Как его под него Unit test писать?

Зло контроллер на JS или нет вопрос филосовский Только асинхронные запросы все равно слать будешь через XMLHttpRequest c его асинхронной моделью. Соответственно асинхронность на сервере тебе по прежнему не нужна. Считай что прокси, который работал на десктопном клиенте уже написан. Стоит только сделать удобную обвязку вокруг всего этого (либ на эту полно).

М>А браузер это не View. И даже класс наследующий WebPage это не View. Это все web специфика.
М>А View, это отдельный класс реализующий определенный интерфейс и занимающийся исключительно своими делами.
М>Ну в крайнем случае, можно чтобы WebPage реализовывал интерфейс View. Правда, при этом нарушается правило, один класс — одна роль.

М>Вот такой я максималист

Если хочешь чтоб все было как в дескотопе — юзай GWT.

Доброго времени суток всем.

Есть клиент-серверное приложение устроенное следующим образом.

Есть интерфейс представляющий модель примерно такой (C#).

interface IModel
{
    byte[] GetData();
    IAsyncResult BeginGetData(AsyncCallback callback);
    byte[] EndGetData(IAsyncResult ar);
}

На клиентской стороне, его реализует прокси, которые ходит к серверу через Web-service.
На серверной стороне, его реализует класс ходящий к базе и содержащий, собственно, логику приложения.

Получается такая схема работы

1. Пользователь жмет кнопку на View (Windows forms)
2. View вызывает метод у Presenter-а, или, если хотите, Controllera.
3. Controller вызывает асинхронный метод IModel.BeginGetData( On_GetDataCompleted ). Никаких лишних потоков, все счастливы.
4. На серверной стороне транспортный уровень вызывает синхронный метод IModel.GetData и пересылает данные клиенту.
5. На клиентской стороне вызывается метод On_GetDataCompleted, берем данные, которые вернул сервер, меняем состояние View.

Теперь стоит задача, сделать Web(AJAX) клиента к этому приложению. Класс Controller-а переезжает на серверную сторону и начинает общаться с моделью через интерфейс IModel напрямую, без посредников. Теперь, когда приходит запрос из браузера, создается экземпляр View и он вызывает метод Controller-а. А Controller, как было написано выше, вызывыет асинхронный метод IModel.BeginGetData и создает еще один, абсолютно не нужный поток на сервере.

Вариантов решения видится несколько.

0. Переделываем Controller, чтобы он всегда вызывал синхронные методы IModel (по факту удаляем асинхронные методы из IModel). На Windows forms клиенте View вызывает методы Controller-а асинхронно (чтобы не вис GUI) и мы миримся с тем, что висит поток ожидающий ответа от сервера. На Web клиенте радуемся жизни.

1. Заводим у Controller-а синхронные и асинхронные методы которые вызывают соответствующие методы IModel. View на обычном клиенте будет вызывать асинхронные методы, а на Web синхронные. (На самом деле у нас нет методов у Controller-а, это я для простоты написал, а есть события View которые Controller обрабатывает. Как завести синхронные и асинхронные события у View тот еще вопрос )

2. Заводим у Controller-а режим работы, синхронный или асинхронный. Сигнатуры методов не меняем. При создании выставляем ему режим работы. Усложняем Controller.

3. Создаем базовую реализацию Controller-а. А для разных клиентов создаем наследников/обертки, которые будут вызывать разные методы IModel, а результаты отдавать в базовую реализацию. Еще сильнее усложняем Controller. Перетестируем его для разных клиентов.

4. Серверная реализация IModel асинхронные методы реализует как обычные. Все равно асинхронные методы Windows forms клиентом не используются. Какая-то злая заточка

5. Какие еще методы решения данной проблемы вы предложите?

Какой бы метод решения выбрали вы? И если не сложно, напишите, почему.

спасибо

Здравствуйте, Максималист, Вы писали:

М>Доброго времени суток всем.

М>Есть клиент-серверное приложение устроенное следующим образом.

М>Есть интерфейс представляющий модель примерно такой (C#).

М>

М>interface IModel
М>{
М>    byte[] GetData();
М>    IAsyncResult BeginGetData(AsyncCallback callback);
М>    byte[] EndGetData(IAsyncResult ar);
М>}
М>

М>На клиентской стороне, его реализует прокси, которые ходит к серверу через Web-service.
М>На серверной стороне, его реализует класс ходящий к базе и содержащий, собственно, логику приложения.
о_О
Т.е. клиент синхронно вызывает метод BeginGetData на сервере? Занятно. Может быть в этом проблема?

М>Получается такая схема работы

М>1. Пользователь жмет кнопку на View (Windows forms)
М>2. View вызывает метод у Presenter-а, или, если хотите, Controllera.
М>3. Controller вызывает асинхронный метод IModel.BeginGetData( On_GetDataCompleted ). Никаких лишних потоков, все счастливы.
Нужно вызвать даленный метод GetData(), но асинхронно.

М>Теперь стоит задача, сделать Web(AJAX) клиента к этому приложению. Класс Controller-а переезжает на серверную сторону и начинает общаться с моделью через интерфейс IModel напрямую, без посредников. Теперь, когда приходит запрос из браузера, создается экземпляр View и он вызывает метод Controller-а. А Controller, как было написано выше, вызывыет асинхронный метод IModel.BeginGetData и создает еще один, абсолютно не нужный поток на сервере.

М>Вариантов решения видится несколько.

М>0. Переделываем Controller, чтобы он всегда вызывал синхронные методы IModel (по факту удаляем асинхронные методы из IModel). На Windows forms клиенте View вызывает методы Controller-а асинхронно (чтобы не вис GUI) и мы миримся с тем, что висит поток ожидающий ответа от сервера. На Web клиенте радуемся жизни.

Как вариант пойдет.

М>5. Какие еще методы решения данной проблемы вы предложите?

Убрать из IModel асинхронные методы как в 0. И завести в контроллере режим работы, чтобы на клиентской стороне он вызывал метод модели асинхронно, а на серверной -синхронно.

М>Какой бы метод решения выбрали вы? И если не сложно, напишите, почему.
Вот последний бы и выбрал. Ибо незачем в модели асинхронные методы + клиент не тупит + на сервере нет лишнего потока.

М>спасибо

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Максималист, Вы писали:

М>>Доброго времени суток всем.

М>>Есть клиент-серверное приложение устроенное следующим образом.

М>>Есть интерфейс представляющий модель примерно такой (C#).

М>>

М>>interface IModel
М>>{
М>>    byte[] GetData();
М>>    IAsyncResult BeginGetData(AsyncCallback callback);
М>>    byte[] EndGetData(IAsyncResult ar);
М>>}
М>>

М>>На клиентской стороне, его реализует прокси, которые ходит к серверу через Web-service.
М>>На серверной стороне, его реализует класс ходящий к базе и содержащий, собственно, логику приложения.
S>о_О
S>Т.е. клиент синхронно вызывает метод BeginGetData на сервере? Занятно. Может быть в этом проблема?

Я не понял, что вы не поняли
Клиент вызывает асинхронный метод прокси. Прокси шлет пакеты на сервер. Серверный транспорт, получив пакеты, вызывает синхронный метод модели. Модель возвращает результат. Сервер шлет пакеты клиенту. Прокси уведомляет через метод обратного вызова, что данные получены
Это как "клиент синхронно вызывает метод BeginGetData на сервере" или асинхронно?
По моему он вообще не вызывает метод на сервере.

Расскажите подробнее если можно, в чем тут может быть проблема? Может я чего-то простого не замечаю.


спасибо

Здравствуйте, Максималист, Вы писали:

М>Здравствуйте, samius, Вы писали:


М>>>На клиентской стороне, его реализует прокси, которые ходит к серверу через Web-service.
М>>>На серверной стороне, его реализует класс ходящий к базе и содержащий, собственно, логику приложения.
S>>о_О
S>>Т.е. клиент синхронно вызывает метод BeginGetData на сервере? Занятно. Может быть в этом проблема?

М>Я не понял, что вы не поняли
М>Клиент вызывает асинхронный метод прокси. Прокси шлет пакеты на сервер. Серверный транспорт, получив пакеты, вызывает синхронный метод модели. Модель возвращает результат. Сервер шлет пакеты клиенту. Прокси уведомляет через метод обратного вызова, что данные получены
Все слишком сложно!
Клиент вызывает асинхронный метод прокси, и ждет пока вызов этого метода не завершится. Я правильно понял? прокси шлет пакеты на сервер, сервер вызывает асинхронный метод модели и только после этого завершает асинхронный метод, сервер шлет пакеты, а прокси на стороне клиента их принимает и понимает что вызов асинхронного метода завершен. Только после этого клиент возвращается в луп сообщений и ждет обратного вызова от сервера, чтобы синхронно вызвать метод EndGetData у прокси, и опять все заново, только обратно с данными.

Таким образом вместо синхронного выполнения одного удаленного метода GetData, клиент выполняет синхронно два удаленных метода, и пока выполняет их втормаживает, но между этими методами обрабатывает сообщения.

М>Это как "клиент синхронно вызывает метод BeginGetData на сервере" или асинхронно?
Синхронно от асинхронно отличается тем, что в случае синхронного вызова, вызывающий поток ждет окончания вызова, а в случае асинхронного — нет. Так вот, вызывая метод у BeginGetData у прокси, вы ждете пока пакеты слетают на сервер, сервер поставит в очередь вызов GetData, пакеты прилетят с сервера и только тогда вызов метода BeginGetData у прокси завершится. Точно так же с EndGetData.

Вместо этой галиматьи вам нужно было вызвать метод прокси GetData(), но вызвать его асинхронно. Т.е. создать делегат с сигнатурой
delegate void GetDataDelegate();
либо
Action

потом
var d = new GetDataDelegate(proxy.GetData);
asyncResult = d.BeginInvoke(EndInvokeCallback, null);
При этом не ожидая даже начала отправки пакетов на сервер вы возвращаетесь в цикл сообщений GUI и ждете вызова EndInvokeCallback, крутясь в цикле сообщений.

В методе EndInvokeCallback вы вызываете
data = d.EndInvoke(asyncResult)
и просто принимаете данные, пришедшие с сервера, либо исключение. Т.е. опять поток GUI не ждет завершения удаленного вызова, как в случае вызова методов Begin/EndGetData у прокси.
При таком подходе удаленно вызывается только один метод, и нет никаких обратных вызовов!!! А это очень важно.

М>По моему он вообще не вызывает метод на сервере.
Считается, что для приложения вызов метода удаленного сервиса "прозрачен", хотя на самом деле летают пакеты.

М>Расскажите подробнее если можно, в чем тут может быть проблема? Может я чего-то простого не замечаю.
Кажется рассказал.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Максималист, Вы писали:

М>>Здравствуйте, samius, Вы писали:


М>>>>На клиентской стороне, его реализует прокси, которые ходит к серверу через Web-service.
М>>>>На серверной стороне, его реализует класс ходящий к базе и содержащий, собственно, логику приложения.
S>>>о_О
S>>>Т.е. клиент синхронно вызывает метод BeginGetData на сервере? Занятно. Может быть в этом проблема?

М>>Я не понял, что вы не поняли
М>>Клиент вызывает асинхронный метод прокси. Прокси шлет пакеты на сервер. Серверный транспорт, получив пакеты, вызывает синхронный метод модели. Модель возвращает результат. Сервер шлет пакеты клиенту. Прокси уведомляет через метод обратного вызова, что данные получены
S>Все слишком сложно!
S>Клиент вызывает асинхронный метод прокси, и ждет пока вызов этого метода не завершится. Я правильно понял? прокси шлет пакеты на сервер, сервер вызывает асинхронный метод модели и только после этого завершает асинхронный метод, сервер шлет пакеты, а прокси на стороне клиента их принимает и понимает что вызов асинхронного метода завершен. Только после этого клиент возвращается в луп сообщений и ждет обратного вызова от сервера, чтобы синхронно вызвать метод EndGetData у прокси, и опять все заново, только обратно с данными.

Нет, не правильно.
Клиент вызывает асинхронный метод прокси, прокси "посылает пакет" и возвращает управление, все, поток освобождается. Никто никого не ждет.
Сервер вызывает синхронный метод модели и отправляет результат клиенту. Когда дынные от сервера пришли на клиент, там поднимается поток в котором вызывается метод обратного вызова клиента.
По факту я использую прокси созданый Visual Studio для доступа к Web servic-у и предоставляемые им асинхронные методы.

S>Таким образом вместо синхронного выполнения одного удаленного метода GetData, клиент выполняет синхронно два удаленных метода, и пока выполняет их втормаживает, но между этими методами обрабатывает сообщения.

надеюсь теперь сумел донести используемую модель, а то мы как-то все не поймем друг друга

Здравствуйте, Максималист, Вы писали:

М>надеюсь теперь сумел донести используемую модель, а то мы как-то все не поймем друг друга
Если я правильно понял, то для получения данных у тебя в интерфейсе есть два метода — GetData и BeginGetData. Причем GetData — синхронный, так почему бы тебе его не использовать в случае браузера вместо асинхронного?

PS
Что-то у тебя там не то, как-то все слишком путано, а как добавились новые требования, так и хороший переколбас нужен. Просто паттерны нужно использовать не ради самих паттернов, а с конкретной целью.

Здравствуйте, samius, Вы писали:


S>Все же я предлагаю убрать асинхронные методы из интерфейса модели.

Видимо, архитектурно это самый лучший вариант. Но так жаль терять готовую асинхронность в Win forms клиенте.
Еще и этот поток будет висеть

Вобщем в рассказах всяких "Фаулеров" о том что можно переиспользовать код есть какая-то натяжка

Здравствуйте, Игoрь, Вы писали:

И>Здравствуйте, Максималист, Вы писали:

М>>надеюсь теперь сумел донести используемую модель, а то мы как-то все не поймем друг друга
И>Если я правильно понял, то для получения данных у тебя в интерфейсе есть два метода — GetData и BeginGetData. Причем GetData — синхронный, так почему бы тебе его не использовать в случае браузера вместо асинхронного?

Не хочу показаться грубым, но, по-моему, я все подробно описал

И>PS
И>Что-то у тебя там не то, как-то все слишком путано, а как добавились новые требования, так и хороший переколбас нужен. Просто паттерны нужно использовать не ради самих паттернов, а с конкретной целью.

Чего ж там запутанного, клиент вызывает веб-сервис прокси, а веб-сервис вызывает модель. Как это еще можно организовать?
Ну можно конечно методы веб-прокси прямо из окошек вызывать, но это не наш метод

Цель была конкретная, автоматическое тестирование клиентского кода (в том числе связанного с UI).
Теперь еще появилась цель, использовать один и тот же клиентский код в Windows forms, и Web клиенте. По моему цель тоже, конкретнее не бывает
Просто использование Windows forms (с его требованием выполнять длительные запросы асинхронно) в первой версии, и наличие в веб-сервис прокси асинхронных методов, привело вот к такому вот решению.
Что Controller будет вызывать асинхронный метод веб-сервис прокси. Для Windows forms решение работает отменно.

Здравствуйте, Максималист, Вы писали:

М>Здравствуйте, samius, Вы писали:


S>>Все же я предлагаю убрать асинхронные методы из интерфейса модели.

М>Видимо, архитектурно это самый лучший вариант. Но так жаль терять готовую асинхронность в Win forms клиенте.
М>Еще и этот поток будет висеть
Не понятно, почему придется терять готовую асинхроннсть в WinForms клиенте. WinForms контроллер может вызывать GetData асинхронно вместо вызывания асинхронного метода модели. Т.е. реализация асинхронного вызова будет не в проксе от IModel, а в WinForms контроллере.

М>Вобщем в рассказах всяких "Фаулеров" о том что можно переиспользовать код есть какая-то натяжка
У "Фаулеров" бывают натяжки, но тут я не вижу ничего натянутого. Различия в тонкостях получения данных у модели можно реализовать с помощью Template Method, применив его к классу контроллера.

Здравствуйте, Игoрь, Вы писали:

И>Здравствуйте, Максималист, Вы писали:

М>><skipped>
И>Знаешь что меня смутило и смущает? Интерфейс IModel. Если тебе понадобилось серьезно изменять интерфейс, значит что-то тут не так. А не так тут было вот что
И>1. В реальности у тебя нет честного асинхронного метода на сервере, более того, судя по архитектуре он там нафиг не нужен, и впихнут он был исключительно как костыль для клиента.
Тут согласен.

И>2. На клиенте у тебя в действительности реализован не прокси. Честный бы прокси переадресовывал асинхронный вызов в асинхронный, а синхронный в синхронный. А ты схитрил, и у тебя асинхронный переадресовывается в синхронный.
Это не у меня, это у Microsoft. Прокси для веб-сервиса генерирует Visual Studio.

И>И смысл такого интерфейса? Если бы его не было, то принципиально ничего не изменилось. Интерфейс — это контракт, и проектировать его нужно так же ответственно, как ты подписываешь контракт в банке.

Изначальный смысл этого интерфейса в том, чтобы можно было безболезненно убрать транспортный слой. Эта задумка сработала.

И>Если у тебя твоё UI требует асинхронности, то нафига костыль было пихать на сервер и размазывать его по всей архитектуре? Вот отсюда и проблема. Адаптер преобразующий синхронность/асинхронность нужно было делать где-то на уровне UI. Мне так кажется.
И>Поэтому решение твоей проблемы с архитектурной точки зренимя, как мне кажется, состоит в том, чтобы привести интерфейс к тому виду, в котором он должен был быть изначально — выкинуть асинхронность на сервере, ну или реализовать честную асинхронность.

Да реализовать не сложно, но как вы верно заметили, на сервере она на фиг не нужна. По крайней мере, на данный момент случаев, когда она могла бы понадобится не вижу.

И>Ну а если архитектурная составляющая встает в противоречие с экономической, тогда делай как проще.

спасибо

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Максималист, Вы писали:

М>>Здравствуйте, samius, Вы писали:


S>>>Все же я предлагаю убрать асинхронные методы из интерфейса модели.

М>>Видимо, архитектурно это самый лучший вариант. Но так жаль терять готовую асинхронность в Win forms клиенте.
М>>Еще и этот поток будет висеть
S>Не понятно, почему придется терять готовую асинхроннсть в WinForms клиенте. WinForms контроллер может вызывать GetData асинхронно вместо вызывания асинхронного метода модели. Т.е. реализация асинхронного вызова будет не в проксе от IModel, а в WinForms контроллере.

Я всю эту бучу поднял, потому что не хотел Controller-ы переписывать. Вернее не переписывать, а использовать одни и те же Controller-ы в обоих клиентах. А если они разные, так вообще ничего менять не надо. Из WinForms Controller-а вызывать BeginGetData, а из вебовского GetData. Я такой вариант предлагал под нумерами 2 и 3.

М>>Вобщем в рассказах всяких "Фаулеров" о том что можно переиспользовать код есть какая-то натяжка
S>У "Фаулеров" бывают натяжки, но тут я не вижу ничего натянутого. Различия в тонкостях получения данных у модели можно реализовать с помощью Template Method, применив его к классу контроллера.

То есть вы бы выбрали, все таки, вариант 3?

Здравствуйте, Ромашка, Вы писали:

Р>Максималист пишет:
>> Теперь стоит задача, сделать Web(AJAX) клиента к этому приложению. Класс
>> Controller-а переезжает на серверную сторону и начинает общаться с
>> моделью через интерфейс IModel напрямую, без посредников.

Р>Проблема вот тут. По сути вы добавляете лишний контроллер.

>> Вариантов решения видится несколько.
>> 5. Какие еще методы решения данной проблемы вы предложите?

Р>Написать другой контроллер.
Р>1. Пользователь жмет кнопку на View (в браузере)
Р>2. Котроллер (на жабаскрипте) лезет в web-service асинхронно
Р>3. Получает данные, отображает в браузере.

>> Какой бы метод решения выбрали вы? И если не сложно, напишите, почему.

Р>Я выбросил бы Controller с серверной стороны и покопался бы в аджаксе.
Р>Потому как ему, по идее, пофиг куда лазить. Собственно, AJAX и есть ваш
Р>Controller, писаный на жабаскрипте.

Интересное мнение, спасибо.

Правда, я считаю, что Controller на JS это зло. Как его под него Unit test писать?
А браузер это не View. И даже класс наследующий WebPage это не View. Это все web специфика.
А View, это отдельный класс реализующий определенный интерфейс и занимающийся исключительно своими делами.
Ну в крайнем случае, можно чтобы WebPage реализовывал интерфейс View. Правда, при этом нарушается правило, один класс — одна роль.

Вот такой я максималист

Здравствуйте, Максималист, Вы писали:

М>Здравствуйте, samius, Вы писали:

М>Я всю эту бучу поднял, потому что не хотел Controller-ы переписывать. Вернее не переписывать, а использовать одни и те же Controller-ы в обоих клиентах. А если они разные, так вообще ничего менять не надо. Из WinForms Controller-а вызывать BeginGetData, а из вебовского GetData. Я такой вариант предлагал под нумерами 2 и 3.
Мне-то отсюда не виднее, нужно/можно ли использовать один контроллер на разные типы клиентов или нет. Но будь они разные, или одинаковые, ни одному из контроллеров не нужны асинхронные методы модели. И WinForms контроллер может спокойно обращаться к GetData() не подвешивая GUI поток, вызывая GetData асинхронно без вспомогательных методов модели BeginGetData и EndGetData.

М>>>Вобщем в рассказах всяких "Фаулеров" о том что можно переиспользовать код есть какая-то натяжка
S>>У "Фаулеров" бывают натяжки, но тут я не вижу ничего натянутого. Различия в тонкостях получения данных у модели можно реализовать с помощью Template Method, применив его к классу контроллера.

М>То есть вы бы выбрали, все таки, вариант 3?
Нет, я к нему склоняюсь, обладая той информацией что вы выложили. При этом я полагаю, что раз рассматривается проблема блокировки GUI при обращении к GetData, то другие проблемы не существенны и во всем остальном архитектура приложения допускает использование одного контроллера для разных клиентов.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Максималист, Вы писали:

М>>Здравствуйте, samius, Вы писали:

М>>Я всю эту бучу поднял, потому что не хотел Controller-ы переписывать. Вернее не переписывать, а использовать одни и те же Controller-ы в обоих клиентах. А если они разные, так вообще ничего менять не надо. Из WinForms Controller-а вызывать BeginGetData, а из вебовского GetData. Я такой вариант предлагал под нумерами 2 и 3.
S>Мне-то отсюда не виднее, нужно/можно ли использовать один контроллер на разные типы клиентов или нет.
Это, так сказать цель, чтобы один контроллер для разных клиентов. Чтобы при изменении логики приложения не приходилось менять и перетестировать оба клиента.

S>Но будь они разные, или одинаковые, ни одному из контроллеров не нужны асинхронные методы модели. И WinForms контроллер может спокойно обращаться к GetData() не подвешивая GUI поток, вызывая GetData асинхронно без вспомогательных методов модели BeginGetData и EndGetData.
Это да. WinForms попутал

М>>>>Вобщем в рассказах всяких "Фаулеров" о том что можно переиспользовать код есть какая-то натяжка
S>>>У "Фаулеров" бывают натяжки, но тут я не вижу ничего натянутого. Различия в тонкостях получения данных у модели можно реализовать с помощью Template Method, применив его к классу контроллера.

М>>То есть вы бы выбрали, все таки, вариант 3?
S>Нет, я к нему склоняюсь, обладая той информацией что вы выложили. При этом я полагаю, что раз рассматривается проблема блокировки GUI при обращении к GetData, то другие проблемы не существенны и во всем остальном архитектура приложения допускает использование одного контроллера для разных клиентов.

спасибо

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, Максималист, Вы писали:

Р>>>Я выбросил бы Controller с серверной стороны и покопался бы в аджаксе.
Р>>>Потому как ему, по идее, пофиг куда лазить. Собственно, AJAX и есть ваш
Р>>>Controller, писаный на жабаскрипте.

М>>Интересное мнение, спасибо.

М>>Правда, я считаю, что Controller на JS это зло. Как его под него Unit test писать?

GIV>Зло контроллер на JS или нет вопрос филосовский Только асинхронные запросы все равно слать будешь через XMLHttpRequest c его асинхронной моделью. Соответственно асинхронность на сервере тебе по прежнему не нужна. Считай что прокси, который работал на десктопном клиенте уже написан. Стоит только сделать удобную обвязку вокруг всего этого (либ на эту полно).

Зло или нет, вопрос действительно философский, а вот как unit test писать, вполне прикладной

М>>А браузер это не View. И даже класс наследующий WebPage это не View. Это все web специфика.
М>>А View, это отдельный класс реализующий определенный интерфейс и занимающийся исключительно своими делами.
М>>Ну в крайнем случае, можно чтобы WebPage реализовывал интерфейс View. Правда, при этом нарушается правило, один класс — одна роль.

М>>Вот такой я максималист

GIV>Если хочешь чтоб все было как в дескотопе — юзай GWT.
Я на Microsoft сижу Но вот в этом я с гуглем согласный

http://code.google.com/intl/ru/webtoolkit/
90% времени уходит на обработку особенностей браузеров, а недостаточная универсальность JavaScript делает совместное использование, тестирование и повторное использование компонентов AJAX сложным и ненадежным. Это неправильно!

спасибо!