Объектный бизнес-уровень LINQ To SQL DataContext

Question

Первоначально я использовал свой объект DataContext как глобальный синглтон. При использовании этого в ASP.Net у меня возникали проблемы с конкуренцией из-за многопоточной природы ASP.Net.

Итак, я провел поиск лучших альтернатив и нашел пост Рика Строла о сценарии "на объект" Таким образом, каждый из моих объектов будет иметь локальный для класса DataContext.

Итак, я понял большинство из них, но у меня возникает вопрос, когда я пытаюсь получить экземпляр объекта. Поскольку все методы являются методами экземпляра, мне нужно сначала получить экземпляр класса. Затем я могу использовать этот экземпляр для вызова метода экземпляра, чтобы получить нужный объект.

Как то так ..

 Customer cust = new Customer();
 cust = cust.GetCustomer(primaryKeyID); // gets data using LINQ-To-SQL

Это просто кажется мне излишним, чтобы создать экземпляр класса, просто чтобы вызвать метод, чтобы вернуть фактический экземпляр, который я хочу. Это правильный способ сделать это? Я думаю, что есть другой способ придерживаться методологии, которую Рик использует в своем блоге.

Пример кода класса:

 public partial class Customer
 {
      MyDataContext db = new MyDataContext(Settings.MyConnectionString);

      public Customer GetCustomer(Int64 custID)
      {
           return db.Customers.SingleOrDefault(c => c.ID == custID);
      }

      public Customer AddCustomer(Customer c)
      {
           db.Customers.InsertOnSubmit(c);
           db.SubmitChanges();
      }
 }

Answer 1

Чтобы ответить только на вопрос об избыточности, не комментируя всю философию «контекст для объекта» или код Рика, который я не рассматривал,

Вы можете удалить две строки с помощью

var customer = new Customer().GetCustomer(primaryKeyId);

Либо создайте фабрику, которая будет действовать как статический шлюз:

public static class CustomerFactory
{
   public static Customer BuildCustomerWithId(_<int/short/long>_ primaryKeyId)
   {
      var customer = new Customer();
      return customer.GetCustomer(primaryKeyId);
   }
}

Это не только очищает создание вашего объекта (теперь вы просто вызываете var customer = CustomerFactory.BuildCustomerWithId(1);), но теперь вы можете при необходимости изменить метод BuildCustomerWithId(), не изменяя классы потребления. Например, позже вы можете решить, что вам не нравится создание экземпляра DataContext в бизнес-объектах, и вы реорганизуете все это. Вместо этого вы можете создать экземпляр DataContext на фабрике, и вам не нужно менять код, вызывающий BuildCustomerWithId(). Статический шлюз делает модульное тестирование немного более сложным, но все же намного проще, чем непосредственное создание экземпляров Customer объектов.

Я понимаю, что это не решает проблему сначала создания экземпляра, а затем вызова метода getter, но, честно говоря, я не вижу в этом проблемы с точки зрения производительности - только с точки зрения синтаксиса / читабельности. 1015 *

Answer 2

Если вы не хотите создавать экземпляр Class для получения экземпляра объекта, вы можете изменить метод GetCustomer на static.

public partial class Customer
{
    public static Customer GetCustomer(Int64 custID)
    {
        using (var db = new MyDataContext(Settings.MyConnectionString))
        {
            return db.Customers.SingleOrDefault(c => c.ID == custID);
        }
    }
    ...
}

И вы можете использовать такой метод:

Customer cust = Customer.GetCustomer(primaryKeyID);

Answer 3

Пример кода класса не закрывает соединение вообще. Таким образом, соединение остается в ожидании, когда сборщик мусора очистит его.

Соединения дешевы, потому что они объединены. Чтобы пул работал эффективно, оставляйте соединения открытыми как можно более короткое время. Я обычно открываю соединение только для выполнения одной функции, например:

using (MyDataContext db = new MyDataContext(conStr))
    return db.Customers.SingleOrDefault(c => c.ID == custID);

Оператор using гарантирует, что соединение возвращается в пул при возврате функции.