asp.net-mvc - 扩展 Entity Framework 应用程序/多个应用程序访问同一个数据库？

Question

我有一个使用 MVC/EF Code First 编程的应用程序。它进行了大量的服务器端处理，并且非常耗费资源。

我知道如何设置负载平衡，但是，我想知道扩展 EF 应用程序是否像配置新服务器、部署应用程序并指向数据库集群一样简单 - 或者我是否会遇到任何问题多个 EF 应用程序访问同一个数据库服务器？

我似乎无法为此找到任何建议/指南，我担心我通过选择 EF 而不是更简单/更直接的选择做出了错误的选择!

Answer 1

... issues ... regards to multiple EF applications hitting the same database server?

回顾一下您的应用程序是基于 ASP .NET MVC 的应用程序这一事实。拥有它的多个实例可能会引发状态管理的幽灵。
MSDN 对 why this is an issue 有很好的介绍:

HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all ASP.NET applications.

Alternatives to session state include the following:

• Application state, which stores variables that can be accessed by all users of an ASP.NET application.

这一点是一种非常常见的存储状态的方式，但是当涉及到一个应用程序的多个实例时就会失效(状态仅对其中一个实例“可见”)。
通常，这可以通过使用 StateServer 来解决。或 SQLServer SessionStateMode 的值.同一篇文章对每个选项进行了很好的总结(重点是我的)。

• StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

• SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

如果您的应用程序是无状态的，这是一个有争议的问题。

I am worrying I made the wrong choice by choosing EF

就访问数据库的应用程序的多个实例的问题而言，任何类型的数据访问技术都会出现问题。
这是基本场景:假设您的应用程序按计划向用户发送欢迎电子邮件。
鉴于表Users :

UserId | Email           | WelcomeLetterSent
-------+-----------------+------------------
     1 | user@domain.com | 0

还有一些伪代码:

foreach (var user in _context.Users.Where(u => !u.WelcomeLetterSent))
{
    SendEmailForUser(user);
    user.WelcomeLetterSent = true;
}

_context.SaveChanges();

有一个 race condition您的应用程序的实例一和实例二可能同时评估 _context.Users.Where(...)在他们有机会设置 WelcomeLetterSent = true 之前并调用 SaveChanges .在这种情况下，可能会向每个用户发送两封欢迎电子邮件，而不是一封。
并发可能是一件阴险的事情。在 here 上有一本关于使用 Entity Framework 管理并发性的入门读物。 ，但这只是冰山一角。
你的问题的答案？这取决于您的应用程序做什么:)

On top of that, I ideally want to build some "extra" support applications that hook in to the same DB... and, I am just not sure how EF will handle multiple apps to the same DB....

如果您的应用程序可以容忍自身访问一个数据库的多个实例，那么让这些“支持应用程序”正常运行通常不是一件容易的事。无论并发是来自一个应用程序的多个实例还是多个应用程序每个实例都有一个实例，这并没有太大区别。