ASP.Net MVC以Web服务为模型？

Question

有没有人有关于在ASP.Net MVC应用程序中使用Web服务作为模型的建议或提示？我没有看到有人写这样做.我想构建一个MVC应用程序,但不是将它绑定到使用特定数据库,也不是将数据库限制为单个MVC应用程序.我觉得一个Web服务(RESTful,很可能是ADO.Net数据服务)是要走的路.

Answer 1

您的MVC应用程序与数据库分离的可能性或有用程度有多大？在您的应用程序生命周期中,您经常看到从SQL Server到Oracle的更改？从我交付的最近10年的项目来看,它从未发生过.

建筑就像洋葱一样,它们在所依赖的东西之上有各种抽象层.如果您打算使用RDBMS进行存储,那么这就是您架构的核心.从数据库中提取自己,以便你可以交换它是一个非常谬误.

现在,您可以将数据库访问与域分离,并且存储库模式是执行此操作的方法之一.目前大多数成熟的解决方案都使用ORM,因此如果您需要成熟的技术,可能需要查看NHibernate,或者在数据之上使用ActiveRecord/linq2sql来查看更简单的活动记录模式.

既然您已经制定了数据策略,那么您就拥有了某种域名.当您向客户端公开数据时,您可以选择通过MVC模式执行此操作,您通常会在其中发送从域生成的DTO以进行呈现,或者您可以决定利用REST之类的体系结构样式来提供更松散耦合的系统,通过提供链接和自定义表示.

当你走向解决方案的外层时,你会从紧耦合变为松散耦合.

但是,如果您的问题是在REST架构或Web服务之上构建MVC应用程序,并将其用作模型......为什么要这么麻烦？如果您要拥有域模型,为什么不在您的系统和服务中重复使用它？

从MVC应用程序生成UI并生成RESTful架构所需的文档是两个完全不同的上下文,基于彼此之间的基础只会导致比需要更多的痛苦.你牺牲了性能.

取决于您的确切场景,但远程基于XML的服务作为MVC中的模型,从经验,不是一个好主意,它可能过度工程并忽视域开始的需要.

Answer 2

2010年11月27日编辑；澄清了我的想法，这确实是需要的。

Web 服务通常会跨不同类型的应用程序公开功能，而不是在单个应用程序中进行抽象。您可能更多地考虑一种封装命令并以不干扰控制器/视图编程的方式读取的方法。

如果您需要解耦并在异步页面中执行异步模式，请使用服务总线中的服务。您可以查看 Rhino.ServiceBus、nServiceBus 和 MassTransit 的 .Net 本机实现，以及RabbitMQ的不同内容http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/。

编辑：我花了一些时间尝试兔子的方式，将消息推送到我的服务，进而将更新推送到簿记应用程序。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：在单独的程序集中创建域层 [aka. 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 世界似乎正在​​朝着我第一次写这个答案时谈到的方向发展，尽管我对新型架构知之甚少。