模型位于单独程序集中的 ASP.NET MVC
我目前正在开发一个.NET 解决方案,其中涉及多个子项目,其中包括一个 ASP.NET MVC 项目。我的模型已被分成一个单独的程序集,因为我需要从解决方案中的各个其他项目中使用它。
我的模型由 ADO.NET 实体框架实体模型组成。我决定为我的模型采用单例模式,并使用以下代码(SalsaEntities 是我的实体模型的名称):
partial class SalsaEntities
{
private static SalsaEntities _instance = new SalsaEntities();
/// <summary>
/// Singleton instance of SalsaEntities.
/// </summary>
public static SalsaEntities Instance
{
get
{
return _instance;
}
}
}
然后,我从其他程序集中使用 SalsaEntities.Instance。这在我的第三个项目(Windows 服务)中工作得很好,尽管我必须在该项目的 App.Config 文件中包含连接字符串。
但是,当我尝试使用 ASP.NET MVC 项目中的 SalsaEntities.Instance 时,出现异常。尽管在项目根目录和 Views 目录中的 Web.config 文件中包含以下内容...
<connectionStrings>
<add name="SalsaEntities" connectionString="metadata=res://*/SalsaModel.csdl|res://*/SalsaModel.ssdl|res://*/SalsaModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=DbSalsa;Integrated Security=True;Pooling=False;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
</connectionStrings>
...我仍然抛出以下异常:
在配置中找不到指定的命名连接、不适合与 EntityClient 提供程序一起使用或无效。
这些程序集都有不同的命名空间,但由于 Windows 服务可以很好地访问它,所以我认为这不是问题。
帮助?
谢谢, David
P.S.:我注意到的另一个怪癖是,当告诉 Visual Studio 创建一个新的强类型视图时,它会生成一个有关模型程序集的文件未找到错误。我在网上多次看到此错误,但没有解决方案。
I currently have a .NET solution I'm developing that involves several sub-projects, including an ASP.NET MVC project. My model has been separated into a separate assembly because I need to use it from the various other projects in the solution.
My model consists of an ADO.NET Entity Framework entity model. I have decided to go with a singleton pattern for my model, with the following code (SalsaEntities being the name of my entity model):
partial class SalsaEntities
{
private static SalsaEntities _instance = new SalsaEntities();
/// <summary>
/// Singleton instance of SalsaEntities.
/// </summary>
public static SalsaEntities Instance
{
get
{
return _instance;
}
}
}
I then consume SalsaEntities.Instance from my other assemblies. This works fine in a third project I have, a Windows Service, although I had to include the connection string in that project's App.Config file.
I am getting an exception, however, when I try to use the SalsaEntities.Instance from my ASP.NET MVC project. Despite including the following in the Web.config files in both the root of the project and in the Views directory...
<connectionStrings>
<add name="SalsaEntities" connectionString="metadata=res://*/SalsaModel.csdl|res://*/SalsaModel.ssdl|res://*/SalsaModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=DbSalsa;Integrated Security=True;Pooling=False;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
</connectionStrings>
...I still have the following exception thrown:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
The assemblies all have different namespaces, but since the Windows Service accesses it just fine, I don't think that's the problem.
Help?
Thanks,
David
P.S.: One more quirk I've noticed is that when telling Visual Studio to create a new strongly-typed View, it generates a file not found error regarding the model assembly. I've seen this error discussed a few times on the web with no resolution.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我不确定这里发生了什么,但 Misha N 问了一个很好的问题。
不过,我确实认为您应该重新考虑 Singleton 模式(至少对于 MVC 应用程序而言)。
随着时间的推移,您的 ObjectContext 将包含越来越多的对象,因此速度会变慢。请参阅此提示了解更多原因。
亚历克斯
I'm not sure what is going on here, but Misha N asks a good question.
However I really think you should reconsider the Singleton pattern (at least for the MVC app).
Overtime your ObjectContext will contain more and more objects and as a result will slow down. See this tip for more on why.
Alex
单例模式不适用于基于 ASP.NET 的应用程序,您需要切换到存储库模式之类的模式,从而在 ASP.NET 请求级别管理 ObjectContext。有几篇文章对此进行了讨论:
如果您愿意,可以从这里开始: http://www.ef -faq.org/objectcontext.html
希望有帮助..
The singleton pattern is not good for ASP.NET based apps you will need to switch to something like a Repository pattern whereby you manage the ObjectContext at the ASP.NET Request level. There are several articles that discuss this:
You can start here if you like: http://www.ef-faq.org/objectcontext.html
Hope that helps..