我正在分析一个潜在的大型网站,我有很多问题.
该网站将使用剃刀视图引擎在ASP.NET MVC 3中编写.在大多数示例中,我发现控制器直接使用底层数据库(使用域/存储库模式),因此之间没有WCF服务.我的第一个问题是：这个架构适合大型交通网站吗？总是可以平衡网站,但这是一个好的方法吗？还是应该让网站使用与数据交互的WCF服务？
问题2：我想采用CQS原则,这意味着我想将查询与命令部分分开.因此,这意味着查询部分将具有与命令部分不同的模型(针对视图进行了优化)(针对业务意图进行了优化,并且仅包含完成命令所需的属性),但都是作用于同一数据库.你认为这是一个好主意吗？
感谢您的建议！
解决方法
>对于可扩展性,它有助于将后端代码与前端代码分开.因此,如果您将UI代码放在MVC项目中以及在一个或多个单独的WCF和业务逻辑项目中尽可能多的处理代码,那么您的代码不仅可以更清晰,而且您还可以独立于每个层次其他.
> CQRS对于高流量网站来说非常棒.我认为CQRS与DDD良好的基础库相结合,即使是低流量网站也是很好的,因为它使业务逻辑更容易实现.将数据分离成读取优化模型和写入优化模型从架构角度来看也是有意义的,因为它使得更改变得更容易(也许更多的工作,但是在不破坏某些东西的情况下进行更改肯定更容易).
> CQRS对于高流量网站来说非常棒.我认为CQRS与DDD良好的基础库相结合,即使是低流量网站也是很好的,因为它使业务逻辑更容易实现.将数据分离成读取优化模型和写入优化模型从架构角度来看也是有意义的,因为它使得更改变得更容易(也许更多的工作,但是在不破坏某些东西的情况下进行更改肯定更容易).
但是,如果两者都在同一个数据库上,我将确保读取模型完全由视图组成,以便您可以根据需要修改实体,而不会破坏读取代码.这样做的优点是您需要编写更少的代码,但是您的写入模型仍将包含一个完整的实体模型,而不仅仅是一个事件存储.
编辑回答您的额外问题：
我喜欢做的是为阅读模型使用WCF数据服务.该技术(特定于.NET 4.0)在数据模型(如Entity Framework EDMX)之上构建了一个OData(=具有LINQ支持的REST Atom)Web服务.
所以,我在sql Server(Views)中构建一个Read模型,然后从中构建一个实体框架模型,然后在只读模式下构建一个WCF数据服务.这听起来比它复杂得多,只需要几分钟.您不需要创建另一个模型,只是将EDMX公开为只读.参见http://msdn.microsoft.com/en-us/library/cc668794.aspx.
命令服务只是一个单向的常规WCF服务,读取服务是WCF数据服务,您的MVC应用程序也同时使用它们.
