ASP.NET MVC 应用程序的体系结构
我正在对一个可能很大的网站进行分析，我有很多问题。
该网站将使用 ASP.NET MVC 3 和 razor 视图引擎编写。在大多数示例中，我发现控制器直接使用底层数据库（使用域/存储库模式），因此中间没有 WCF 服务。我的第一个问题是：这种架构适合流量大的大网站吗？始终可以对站点进行负载平衡，但这是一个好方法吗？或者我应该让站点使用与数据交互的 WCF 服务？
问题2：我想采用CQS原则，这意味着我想将查询和命令部分分开。因此，这意味着查询部分将具有与命令部分（针对业务意图优化并且仅包含完成命令所需的属性）不同的模型（针对视图进行优化） - 但两者都作用于同一个数据库。你认为这是个好主意吗？
感谢您的建议！
I'm in the process of doing the analysis of a potentially big web site, and I have a number of questions.
The web site is going to be written in ASP.NET MVC 3 with razor view engine. In most examples I find that controllers directly use the underlying database (using domain/repository pattern), so there's no WCF service in between. My first question is: is this architecture suitable for a big site with a lot of traffic? It's always possible to load balance the site, but is this a good approach? Or should I make the site use WCF services that interact with the data?
Question 2: I would like to adopt CQS principles, which means that I want to separate the querying from the commanding part. So this means that the querying part will have a different model (optimized for the views) than the commanding part (optimized to business intend and only containing properties that are needed for completing the command) - but both act on the same database. Do you think this is a good idea?
Thanks for the advice!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为了可扩展性，它有助于将后端代码与前端代码分开。因此，如果您将 UI 代码放在 MVC 项目中，并将尽可能多的处理代码放在一个或多个单独的 WCF 和业务逻辑项目中，那么您的代码不仅会更清晰，而且还能够独立地扩展层/层其他。
CQRS 非常适合高流量网站。我认为 CQRS 与 DDD 的良好基础库正确结合，即使对于低流量站点也很好，因为它使业务逻辑更容易实现。从架构的角度来看，将数据分离为读取优化模型和写入优化模型是有意义的，因为它使更改更容易进行（可能需要更多工作，但在不破坏某些内容的情况下进行更改肯定更容易）。
但是，如果两者都作用于同一个数据库，我将确保读取模型完全由视图组成，以便您可以根据需要修改实体而不会破坏读取代码。这样做的优点是您需要编写更少的代码，但您的编写模型仍将包含成熟的实体模型而不仅仅是事件存储。
编辑来回答您的额外问题：
我喜欢做的是将 WCF 数据服务用于读取模型。该技术（特定于 .NET 4.0）在数据模型（例如实体框架 EDMX）之上构建 OData（= REST + Atom，支持 LINQ）Web 服务。
因此，我在 SQL Server（视图）中构建一个读取模型，然后从中构建一个实体框架模型，然后在其上以只读模式构建一个 WCF 数据服务。这听起来比实际复杂得多，只需要几分钟。您不需要创建另一个模型，只需将 EDMX 公开为只读即可。另请参阅 http://msdn.microsoft.com/en-us/library/cc668794 .aspx。
命令服务只是一种单向常规 WCF 服务，读取服务是 WCF 数据服务，并且您的 MVC 应用程序会使用它们。
For scalability, it helps to separate back-end code from front-end code. So if you put UI code in the MVC project and as much processing code as possible in one or more separate WCF and business logic projects, not only will your code be clearer but you will also be able to scale the layers/tiers independently of each other.
CQRS is great for high-traffic websites. I think CQRS, properly combined with a good base library for DDD, is good even for low-traffic sites because it makes business logic easier to implement. The separation of data into a read-optimized model and a write-optimized model makes sense from an architectural point of view also because it makes changes easier to do (maybe some more work, but it's definitely easier to make changes without breaking something).
However, if both act on the same database, I would make sure that the read model consists entirely of Views so that you can modify entities as needed without breaking the Read code. This has the advantage that you'll need to write less code, but your write model will still consist of a full-fledged entity model rather than just an event store.
EDIT to answer your extra questions:
What I like to do is use a WCF Data Service for the Read model. This technology (specific to .NET 4.0) builds an OData (= REST + Atom with LINQ support) web service on top of a data model, such as an Entity Framework EDMX.
So, I build a Read model in SQL Server (Views), then build an Entity Framework model from that, then build a WCF Data Service on top of that, in read-only mode. That sounds a lot more complicated than it is, it only takes a few minutes. You don't need to create yet another model, just expose the EDMX as read-only. See also http://msdn.microsoft.com/en-us/library/cc668794.aspx.
The Command service is then just a one-way regular WCF service, the Read service is the WCF Data Service, and your MVC application consumes them both.