Редактировать 2010-11-27; прояснил мои мысли, которые действительно были необходимы.
Веб-сервис предоставляет функциональность для различных типов приложений, а не для абстракции в одном приложении, чаще всего. Вы, вероятно, думаете о способе инкапсуляции команд и чтения таким образом, который не мешает программированию вашего контроллера / представления.
Используйте сервис из служебной шины, если вы хотите отделиться и выполните асинхронный шаблон на ваших асинхронных страницах. Вы можете увидеть Rhino.ServiceBus, nServiceBus и MassTransit для собственных реализаций .Net и RabbitMQ для чего-то другого http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/.
Редактировать: у меня было некоторое время, чтобы попробовать кролика таким образом, чтобы он передавал сообщения в мой сервис, что, в свою очередь, приводило к обновлению приложения для бухгалтерского учета. RabbitMQ - это брокер сообщений, он же MOM (промежуточное программное обеспечение, ориентированное на сообщения), и вы можете использовать его для отправки сообщений на сервер приложений.
Вы также можете просто предоставить сервисные интерфейсы. Прочитайте Эрик Эван, управляемый доменом, для более подробного описания.
Сервисные интерфейсы REST-ful имеют дело с данными, а точнее с адресуемыми ресурсами. Это может значительно упростить вашу программную модель и дает отличный контроль над выводом по протоколу HTTP. Предстоящая модель программирования WCF использует истинный отдых, как определено в исходном тезисе, где каждый документ должен в некоторой степени предоставлять URI для продолжения навигации. посмотрите на это .
(В моей первой версии этого поста я оплакивал REST как «медленный», что бы это ни значило) API на основе REST также в значительной степени используются в CouchDB и Riak .
ADO.Net - это довольно дерьмо (!) [N + 1 проблем с отложенным сбором данных из-за кода для реализации, утечки доступа к данным - вам всегда нужен контекст БД, где находится код запроса и т. Д.), По сравнению с пример LightSpeed (коммерческий) или NHibernate. Spring.Net также позволяет вам обернуть интерфейсы сервисов в их содержимое фасадом веб-сервиса, но (не просматривая его некоторое время), я думаю, что он немного перегружен в своей конфигурации.
Редактировать 1: Под ADO.Net здесь я подразумеваю «лучшую практику» по умолчанию с DataSets, DataAdapter и итерацией большого количества строк из DataReader; это порождает довольно уродливый и трудный для отладки код. Да, N + 1 - это структура сущностей.
(Редактировать 2: EntityFramework меня тоже не впечатляет!)
Редактировать 1: Создайте свой доменный слой в отдельной сборке [aka. Core] и предоставьте там все доменные и прикладные сервисы, затем импортируйте эту сборку из вашего конкретного приложения MVC. Оберните доступ к данным в некотором DAO / Repository через интерфейс в вашей базовой сборке, на который затем ссылается и реализует ваша сборка данных. Подключите интерфейс и реализацию с IoC. Вы даже можете запрограммировать что-то для динамического обнаружения услуг с помощью вышеупомянутых сервисных шин, чтобы решить для интерфейсов. WCF использует такие интерфейсы, как и большинство вышеупомянутых сервисных шин; вы можете предоставить субкомпонентрезольвер в вашем контейнере IoC, чтобы сделать это автоматически.
Редактировать 2:
Отличным комбо для вышеперечисленного будет CQRS + EventSourcing + ReactiveExtensions. Ваша модель записи будет принимать команды, ваша модель домена будет решать, принимать ли их, она будет отправлять события в конвейер реактивных расширений, возможно, также через RabbitMQ, который будет использовать ваша модель чтения.
Обновление 2010-01-02 (правка 1)
Шутка моей идеи была записана чем-то под названием MindTouch Dream. Они сделали скринкаст, где рассматривают почти все части веб-приложения как (веб) -сервис, который также предоставляется с помощью REST.
Они создали высокопараллельную среду, использующую для этого сопрограммы, включая собственный пул эластичных потоков.
Всем недоброжелателям в этом вопросе перед вами лицо: р! Послушайте этот скриншот, , особенно в 12 минут.
Фактические рамки здесь.
Если вы занимаетесь программированием такого типа, посмотрите , как работают монады и их реализации в C # . Вы также можете прочитать о CoRoutines .
С новым годом!
Обновление 2010-11-27 (правка 2)
Оказалось, что CoRoutines были созданы с помощью параллельной библиотеки задач от Microsoft. Ваша задача теперь реализует те же функции, что и IAsyncResult. Caliburn - это крутой фреймворк, который их использует.
Реактивные Расширения подняли понимание монады на следующий уровень асинхронности.
Мир ALT.Net, кажется, движется в направлении, о котором я говорил, когда писал этот ответ впервые, хотя с новыми типами архитектур, о которых я мало знал.