问题描述
我正在ASP.NET应用程序中尝试使用Linq to SQL，该应用程序使用具有大量外键(超过100个表)的大型数据库. Linq如何允许您创建完好所有关系的数据上下文，然后创建自动联接表的Linq语句，这给我留下了深刻的印象.但是，这引出了一个问题:如果我要提交仅适用于一个或两个表的Linq语句，那么拥有只包含必要的一个或多个表的datacontext会更好吗?在我看来，如果我用数据库中的所有表构建一个数据上下文，它将非常庞大，并且每次使用Linq加载该数据上下文都会对性能产生负面影响.我说的对吗?
I am trying out Linq to SQL in an ASP.NET application that uses a large database with lots of foreign keys (100+ tables). I am impressed with how Linq permits you to create a datacontext with all of your relationships intact and to then create Linq statements that automatically join tables. However, this leads to a question: if I am submitting a Linq statement that just works with one or two tables, is it better to have a datacontext that just has the necessary table/tables? It seems to me that if I build a datacontext with all of the tables in the database, it would be quite massive and loading it for every use of Linq would have a negative impact on performance. Am I right?
评论:我知道只能根据需要创建数据上下文(但是仍然感谢您提及它).问题实际上是关于我是否应该有很多小的数据上下文，或者建立一个大的数据上下文是否可以.
Comment: I know to create the datacontext only as needed (but thank you nonetheless for mentioning it). The question is really about whether I should have lots of little datacontexts or whether it would be Ok to build one big one.
推荐答案
每一组已连接表中应具有一个DataContext.在大多数应用程序中，这意味着所有内容都需要一个DataContext.如果碰巧有几组表不需要一起修改，则可以考虑使用多个DataContext.如果甚至可能需要跨DataContext查询，请不要将它们分开.
You should have one DataContext per one group of connected tables. In most applications, this means one DataContext for everything. If you happen to have several sets of tables that you do not need to modify together, you might consider several DataContexts. If you even might need to query across DataContexts, do not separate them.
DataContext不仅是一组表-它是Data Gateway模式的实现-您可以用返回所需数据的方法填充它，因此不必对每个数据库进行硬编码查询您的应用程序的一角.现在，如果您有多个DataContext，每页一个，那么您很可能最终不得不在其中的每一个中都坚持使用您的通用功能(想想MyDataContext.GetActiveCustomers()).这将是可怕的重复.
A DataContext is not just a set of tables - it is meant to be an implementation of the Data Gateway pattern - you can fill it with methods that return the data you need, so you don't have to hardcode queries into every corner of your application. Now, if you had multiple DataContexts, one per page, you would very likely end up having to stick your common functionality (think MyDataContext.GetActiveCustomers()) in every one of them. This would be horrible duplication.
因此答案是，通常无法构建许多小的DataContext.仅当您的数据是完全独立的(不同的逻辑或物理数据库)或者您仅将DataContext用作Connection对象(并非必须如此)时，这才可行.
So the answer is that it is usually not OK to build many small DataContexts. This is only feasible if your data is completely separate (different logical or physical databases) or if you are using DataContext as simply a Connection object, which it is not meant to be.
但是请注意，DataContext应该是短命的-它们是工作单位模式的实现，因此它们的生存期应等于一个逻辑操作(例如，加载一组产品或插入新订单).创建和销毁DataContext便宜，因此不要浪费时间将它们缓存起来.
Do note however, that DataContexts should be short-lived - they are an implementation of the Unit of Work pattern and thus their lifetime should be equal to one logical operation (e.g. loading a set of products or inserting a new order). DataContexts are cheap to create and destroy, so do not waste time caching them just because.
这篇关于Linq to SQL:在每个页面或全局页面中使用一个较小的DataContext更好吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！