C＃中的嵌套连接

Question

I recently created a light weight ORM tool in C# and posted it on github. https://www.github.com/RiceRiceBaby/ADOCRUD . One of the things my ORM does is manage the opening and closing of connections for you. The way I do this is I open the connection in the constructor of my context class and close it on dispose. The code below is an example of how to use my tool.

using (ADOCRUDContext context = new ADOCRUDContext(connectionString)
{
     context.Insert<Product>(p);
     context.Commit();
}

The problem with me implementing this automatic management of connection is that it prevents nested connections from working. For example, the following will not work:

public Product GetProductById(int productId)
{
  Product p = null;

  using (ADOCRUDContext context = new ADOCRUDContext(connectionString))
  {
    p = context.QueryItems<Product>("select * from dbo.Product where Id = @id", new { id = productId }).FirstOrDefault();
  }

  return p;
}

public void UpdateProduct(int productId)
{
  using (ADOCRUDContext context = new ADOCRUDContext(connectionString))
  {
    Product p = this.GetProductById(productId);
    p.Name = "Basketball";
    context.Update<Product>(p);
    context.Commit();
  }
}

The reason this won't work is because the last brace in the using statement of the method GetProductId method will close the sql connections for both GetProductId context and UpdateProduct context. This means that context.Update<Product>(p); will throw an exception because the connection has already been closed.

I thought this automatic management of connections is a good idea but I'm afraid people might not use my tool if they don't have the ability to have nested connections. Is there a way to keep this management of connections while allowing nested connections like the code above?

Answer 1

You could use reference counting to keep track of how many using statements the code goes through and to properly close the context at the right time, and then a single using statement on the outside of a block with multiple database calls will force the use of the same context instance.

using (var context = this.contextManager.GetContext(connectionString))
{
    var product = DL.GetProductById(id);
    product.name = "The Best Product";
    DL.UpdateProduct(product);
}

You can see an example of reference counting in the CSLA DbContextManager Class .

However, many modern applications use a dependency injection container to control the lifetime of the DB Context. So it would make sense if there were a way to do it that way as an alternative to reference counting (actually, your current ADOCRUDContext would probably work if it were injected into the constructor of the classes that use it, but it might make sense to wrap the connection string into another object so it can be injected without explicit configuration, and swapped more easily).

Also, many would argue that having to new up your ADOCRUDContext inline is anti-pattern because there is no way to mock the context (hence, no way to test it). A way around that would be to use an abstract factory pattern to allow injecting the context into the class.

Answer 2

I am surprised that nobody said that the first analysis of the issue is wrong.

I am right to all of your answer

• multiple using will cause bugs like in this case
• use separated connections
• use factory

Ok ok but the first issue of this code is just the object

Product p = this.GetProductById(productId);

will lose its context and the first using want to use a disconnected object and that is forbidden. But if you attached this object to the first context opened you can reuse it and do your Update .

To summarize, you have these steps

1. USING, open 1st context
2. call to GetProductById
3. USING 2nd context
4. Get the product in the 2nd context
5. Close and Dispose 2nd context
6. Update properties of Product returned in the 1st context
7. Update product in the 1st context
8. ERROR: the product returned is disconnected

Now you must have

1. USING, open 1st context
2. call to GetProductById
3. USING 2nd context
4. Get the product in the 2nd context
5. Close and Dispose 2nd context
6. Update properties of Product returned in the 1st context
7. ATTACH Product object to the first context
8. Update product in the 1st context
9. OK The Product is updated

Try this code to attach

var entry = context.Entry(entity);
if (entry != null)
{
     entry.State = EntityState.Modified;
}

EDIT

Like we discuss in comments, the issue comes from the source code of ADOCRUDContext

The member sqlConnection and sqlTransaction are marked static and should not.

Correction was done when I wrote these lines. It is just to marked as solution for others

Answer 3

No, do not create some magic which would allow your example code to function over multiple using statements as that's not expected. A using statement is created just to be able to control the cleanup/lifetime of the object.

If you bypass that, you take way the control from your user.

The most sane approach is to simply pass the context in the class constructor (or simply create the context in the constructor). By doing so, all methods would share the same context.

The other approach is to do something like TransactionScope . ie be able to share an internal scope but also be able to explicitly tell if a new scope is required.

public Product GetProductById(int productId)
{
  Product p = null;

  using (ADOCRUDContext context = new ADOCRUDContext(connectionString))
  {
    p = context.QueryItems<Product>("select * from dbo.Product where Id = @id", new { id = productId }).FirstOrDefault();
  }

  return p;
}

public void UpdateProduct(int productId)
{
  //see the second argument
  using (ADOCRUDContext context = new ADOCRUDContext(connectionString, Options.ReuseExisting))
  {
    Product p = this.GetProductById(productId);
    p.Name = "Basketball";
    context.Update<Product>(p);
    context.Commit();
  }
}

However, that requires you to deal with [ThreadStatic] variable within your ADOCRUDContext that keeps track of the currently open context. Do note that [ThreadStatic] do not work very well with TPL/Tasks. Thus this approach is much more complex since you need to be aware of how different threading techniques work i .NET.