c# - 使用 c# 为 linqpad 创建 DynamicDataContextDriver

Question

我正在尝试创建驱动程序linqpad并有疑问：

当我创建时DynamicDataContextDriver，我必须创建类TypedDataContext。

1. 我应该在里面放什么？
2. 它将如何填充？
3. 我可以控制它的填充方式吗？
4. 如果我在这里使用对象数据库，有什么我必须记住的吗？

我在这里找到了一些答案，但我在上面找不到所有答案。

Answer 1

A typed data context is simply a class with properties/fields suitable for querying. Those properties/fields will typically return IEnumerables or IQueryables. For example:

public class TypedDataContext
{
   public IEnumerable<Customer> Customers { get { ... } }
   public IEnumerable<Order> Orders { get { ... } }
   ...
}

When you use Visual Studio to create a new item of kind "LINQ to SQL classes" or "ADO.NET Entity Data Model", Visual Studio creates a typed data context for you which is an excellent example of what LINQPad expects. A typed data context can also expose methods (e.g., to map stored procedures or functions) - in fact it can expose anything that makes sense to the end user.

When you execute a query in LINQPad that has a connection, LINQPad subclasses the typed data context associated with the connection so that the query has access to all of its fields/properties. This is why Customers.Dump() is a valid query - we can just access Customers without having to instantiate the typed data context first.

A LINQPad driver can work in one of two ways. Either it can act like Visual Studio and build the typed data context automatically and on the fly (dynamic data context driver), or it can extract a typed data context from an existing assembly provided by the user (static data context driver). When you add a connection in LINQPad, you'll notice that the drivers are listed in two list boxes (Build data context automatically = dynamic driver, and Use a typed data context from your own assembly = static driver).

The typed data context is instantiated whenever a query executes. Because its properties typically return lazily evaluated IEnumerables/IQueryables, it's not helpful to think of "populating" it. However, it will need to know how to access an underlying data source, and this is done by passing arguments into the constructor.

LINQPad normally keeps the query's application domain alive between query runs, and this might be useful with caching and optimization should you be writing a driver for an object database. Other than that, there shouldn't be any special considerations for object databases.