以 Web 服务为模型的 ASP.Net MVC？
有人对在 ASP.Net MVC 应用程序中使用 Web 服务作为模型有建议或技巧吗？ 我还没有看到有人写过关于这样做的文章。 我想构建一个 MVC 应用程序，但不将其与使用特定数据库绑定，也不将数据库限制为单个 MVC 应用程序。 我觉得 Web 服务（RESTful，很可能是 ADO.Net Data Services）是最佳选择。
Does anyone have advice or tips on using a web service as the model in an ASP.Net MVC application? I haven't seen anyone writing about doing this. I'd like to build an MVC app, but not tie it to using a specific database, nor limit the database to the single MVC app. I feel a web service (RESTful, most likely ADO.Net Data Services) is the way to go.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的 MVC 应用程序与数据库分离的可能性有多大，或者有用吗？ 在您的应用程序生命周期中，您多久会看到从 SQL Server 到 Oracle 的更改？ 从我过去 10 年交付的项目来看，这种情况从未发生过。
架构就像洋葱，它们在它们所依赖的事物之上有抽象层。 如果您打算使用 RDBMS 进行存储，那么这就是您的架构的核心。 将自己从数据库中抽象出来以便可以交换它是非常错误的。
现在，您可以将数据库访问与域分离，而存储库模式就是实现这一目标的方法之一。 如今大多数成熟的解决方案都使用 ORM，因此如果您想要成熟的技术，您可能需要看看 NHibernate，或者 ActiveRecord / linq2sql 在数据之上获得更简单的活动记录模式。
现在您已经制定了数据策略，您就拥有了某种领域。 当您向客户端公开数据时，您可以选择通过 MVC 模式来实现，通常会发送从您的域生成的 DTO 进行渲染，或者您可以决定利用 REST 等架构风格来提供更松散耦合的系统，通过提供链接和自定义表示。
当您转向解决方案的外部层时，您会从紧密耦合变为松散耦合。
然而，如果您的问题是在 REST 架构或 Web 服务之上构建 MVC 应用程序，并将其用作模型......为什么还要麻烦呢？ 如果您打算拥有一个域模型，为什么不在您的系统和服务中重用它呢？
从 MVC 应用程序生成 UI 和生成 RESTful 架构所需的文档是两个完全不同的上下文，将一个上下文相互叠加只会导致比需要的更多的痛苦。 而且你正在牺牲性能。
取决于您的具体场景，但从经验来看，将基于 XML 的远程服务作为 MVC 中的模型并不是一个好主意，它可能是过度设计并忽略了对域的需求。
How likely, or useful, is it for your MVC app to be decoupled from your database? How often have you seen, in your application lifetime, a change from SQL Server to Oracle? From the last 10 years of projects I've delivered, it's never happened.
Architectures are like onions, they have layers of abstractions above things they depend on. And if you're going to use an RDBMS for storage, that's at the core of your architecture. Abstracting yourself from the DB so you can swap it around is very much a fallacy.
Now you can decouple your database access from your domain, and the repository pattern is one of the ways to do that. Most mature solutions use an ORM these days, so you may want to have a look at NHibernate if you want a mature technology, or ActiveRecord / linq2sql for a simpler active record pattern on top of your data.
Now that you have your data strategy in place, you have a domain of some sort. When you expose data to your client, you can choose to do so through an MVC pattern, where you'll usually send DTOs generated from your domain for rendering, or you can decide to leverage an architecture style like REST to provide more loosely coupled systems, by providing links and custom representations.
You go from tight coupling to looser coupling as you go towards the external layers of your solution.
If your question however was to build an MVC app on top of a REST architecture or web services, and use that as a model... Why bother? If you're going to have a domain model, why not reuse it in your system and your services where it makes sense?
Generating a UI from an MVC app and generating documents needed for a RESTful architecture are two completely different contexts, basing one on top of each other is just going to cause much more pain than needed. And you're sacrificing performance.
Depends on your exact scenario, but remote XML-based service as the model in MVC, from experience, not a good idea, it's probably over-engineering and disregarding the need for a domain to start with.
2010年11月27日编辑； 澄清了我的想法，这确实是需要的。
Web 服务通常会跨不同类型的应用程序公开功能，而不是在单个应用程序中进行抽象。 您可能更多地考虑一种封装命令并以不干扰控制器/视图编程的方式读取的方法。
如果您需要解耦并在异步页面中执行异步模式，请使用服务总线中的服务。 您可以查看 Rhino.ServiceBus、nServiceBus 和 MassTransit 的 .Net 本机实现，以及 RabbitMQ 的不同内容 http://blogs.digitar.com/jjww/2009/01/rabbits-和-沃伦斯/。
编辑：我花了一些时间尝试兔子的方式，将消息推送到我的服务，进而将更新推送到簿记应用程序。 RabbitMQ 是一个消息代理，又名 MOM（面向消息的中间件），您可以使用它向应用程序服务器发送消息。
您也可以简单地提供服务接口。 阅读 Eric Evan 的领域驱动设计以获取更详细的描述。
REST 式服务接口处理大量数据，更具体地说，处理可寻址资源。 它可以极大地简化您的编程模型，并允许通过 HTTP 协议对输出进行很好的控制。 WCF 即将推出的编程模型使用原始论文中定义的真正的休息，其中每个文档都应该在某种程度上提供 URI 以便继续导航。 有一个 看看这个。
（在这篇文章的第一个版本中，我感叹 REST 太“慢”了，不管这意味着什么）基于 REST 的 API 也差不多是 CouchDB 和 Riak用途。
与 LightSpeed (商业）或 NHibernate。 Spring.Net 还允许您使用 Web 服务外观将服务接口包装在其包含中，但是（没有浏览它一段时间）我认为它的配置有点过于 xmly。
编辑 1：这里的 ADO.Net 是指使用 DataSet、DataAdapter 和从 DataReader 迭代大量行的默认“最佳实践”； 它会产生相当丑陋且难以调试的代码。 N+1 的东西，是的，就是关于实体框架的。
（编辑 2：EntityFramework 也没有给我留下深刻的印象！）
编辑 1：在单独的程序集中创建域层 [又名。 Core] 并在那里提供所有域和应用程序服务，然后从特定的 MVC 应用程序导入此程序集。 通过核心程序集中的接口将数据访问包装在某些 DAO/存储库中，然后数据程序集引用并实现该接口。 使用 IoC 连接接口和实现。 您甚至可以使用上述服务总线进行动态服务发现编程，以解决接口问题。 WCF 使用这样的接口，上述大多数服务总线也是如此； 您可以在 IoC 容器中提供一个子组件解析器来自动执行此操作。
编辑2：
上述的一个很好的组合是 CQRS+EventSourcing+ReactiveExtensions。 您的写入模型将接受命令，您的域模型将决定是否接受它们，它将事件推送到反应扩展管道，也许还通过 RabbitMQ，您的读取模型将使用它。
更新 2010-01-02（编辑 1）
我的这个笑话已经被一个叫做 MindTouch Dream 的东西编成了代码。 他们制作了一个截屏视频，其中将 Web 应用程序的几乎所有部分都视为（Web）服务，该服务也通过 REST 公开。
他们使用协同例程创建了一个高度并行的框架来处理这个问题，包括他们自己的弹性线程池。
对于这个问题上所有反对者，当着你的面：p！ 听这个屏幕 -演员阵容，，尤其是在 12 分钟时。
实际框架在这里。
如果您喜欢这种编程，请查看monad 的工作原理 和 它们在 C# 中的实现。 您还可以阅读 CoRoutines。
新年快乐！
更新2010-11-27（编辑2）
事实证明，CoRoutines 是通过 Microsoft 的任务并行库产品化的。 您的任务现在实现了相同的功能，因为它实现了 IAsyncResult。 Caliburn 是一个使用它们的很酷的框架。
反应式扩展将 monad 理解提升到了异步的新水平。
ALT.Net 世界似乎正在朝着我第一次写这个答案时谈到的方向发展，尽管我对新型架构知之甚少。
Edit 2010-11-27; clarified my thoughts, which was really needed.
A web service exposes functionality across different types of applications, not for abstraction in one single application, most often. You are probably thinking more of a way of encapsulating commands and reads in a way that doesn't interfere with your controller/view programming.
Use a service from a service bus if you're after the decoupling and do an async pattern in your async pages. You can see Rhino.ServiceBus, nServiceBus and MassTransit for .Net native implementations and RabbitMQ for something different http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/.
Edit: I've had some time to try rabbit out in a way that pushed messages to my service which in turn pushed updates to the book keeping app. RabbitMQ is a message broker, aka a MOM (message oriented middle-ware) and you could use it to send messages to your application server.
You can also simply provide service interfaces. Read Eric Evan's Domain Driven Design for a more detailed description.
REST-ful service interfaces deal a lot with data, and more specifically with addressable resources. It can greatly simplify your programming model and allows great control over output through the HTTP protocol. WCF's upcoming programming model uses true rest as defined in the original thesis, where each document should to some extent provide URIs for continued navigation. Have a look at this.
(In my first version of this post, I lamented REST for being 'slow', whatever that means) REST-based APIs are also pretty much what CouchDB and Riak uses.
ADO.Net is rather crap (!) [N+1 problems with lazy collection because of code-to-implementation, data-access leakage - you always need your db context where your query code is etc] in comparison to for example LightSpeed (commercial) or NHibernate. Spring.Net also allows you to wrap service interfaces in their contain with a web service facade, but (without having browsed it for a while) I think it's a bit too xmly in its configuration.
Edit 1: With ADO.Net here I mean the default "best practice" with DataSets, DataAdapter and iterating lots of rows from a DataReader; it breeds rather ugly and hard-to-debug code. The N+1 stuff, yes, that is about the entity framework.
(Edit 2: EntityFramework doesn't impress me either!)
Edit 1: Create your domain layer in a separate assembly [aka. Core] and provide all domain and application services there, then import this assembly from your specific MVC application. Wrap data access in some DAO/Repository, through an interface in your core assembly, which your Data assembly then references and implements. Wire up interface and implementation with IoC. You can even program something for dynamic service discovery with the above mentioned service buses, to solve for the interfaces. WCF uses interfaces like this and so do most of the above service busses; you can provide a subcomponentresolver in your IoC container to do this automatically.
Edit 2:
A great combo for the above would be CQRS+EventSourcing+ReactiveExtensions. Your write-model would take commands, your domain model would decide whether to accept them, it would push events to the reactive-extensions pipeline, perhaps also over RabbitMQ, which your read-model would consume.
Update 2010-01-02 (edit 1)
The jest of my idea has been codified by something called MindTouch Dream. They have made a screencast where they treat almost all parts of a web application as a (web)-service, which also is exposed with REST.
They have created a highly parallel framework using co-routines to handle this, including their own elastic thread pool.
To all the nay-sayers in this question, in ur face :p! Listen to this screen-cast, especially at 12 minutes.
The actual framework is here.
If you are into this sort of programming, have a look at how monads work and their implementations in C#. You can also read up on CoRoutines.
Happy new year!
Update 2010-11-27 (edit 2)
It turned out CoRoutines got productized with the task parallel library from Microsoft. Your Task now implement the same features, as it implements IAsyncResult. Caliburn is a cool framework that uses them.
Reactive Extensions took the monad comprehensions to the next level of asynchronocity.
The ALT.Net world seems to be moving in the direction I talked about when I wrote this answer the first time, albeit with new types of architectures I knew little of.
您应该以与数据访问无关的方式定义模型，例如使用存储库模式。 然后，您可以创建由特定数据访问技术（Web 服务、SQL 等）支持的具体实现。
You should define your models in a data access agnostic way, e.g. using Repository pattern. Then you can create concrete implementations backed by specific data access technologies (Web Service, SQL, etc).
这实际上取决于这个 mvc 项目的大小。 如果网站将由少数用户（< 5000）使用，我会说将 UI 和域保持在相同的运行环境中。
另一方面，如果您计划建立一个将有数百万人访问的网站，您必须考虑分布式，这意味着您需要以可以扩展/扩展的方式构建您的网站。 这意味着您可能需要使用额外的服务器（Web、应用程序和数据库）。
为了使其正常工作，您需要将 mvc UI 站点与应用程序解耦。 应用程序层通常包含域模型，并且可能通过 WCF 或服务总线公开。 我更喜欢服务总线，因为它更可靠，并且可能使用像 msmq 这样的持久队列。
我希望这有帮助
It really depends on the size of this mvc project. I would say keep the UI and Domain in same running environment if the website is going to be used by a small number of users ( < 5000).
On the other side, if you are planning on a site that is going to be accessed by millions, you have to think distributed and that means you need to build your website in a way that it can scale up/out. That means you might need to use extra servers (Web, application and database).
For this to work nicely, you need to decouple your mvc UI site from the application. The application layer would usually contain your domain model and might be exposed through WCF or a service bus. I would prefer a Service Bus because it is more reliable and might use persistent queues like msmq.
I hope this helps