В настоящее время у меня есть класс, подобный приведенному ниже (пропущенная проверка ошибок)
В настоящее время это то, как база данных обернута в более простые в использовании объекты.
Мне было интересно, если я собираюсь загружать, скажем, 50 000 заказов, если я буду создавать адаптеры таблицы один раз, а затем повторно использовать их вместо создания нового адаптера таблицы для каждого заказа?
Я не видел, чтобы какие-то проблемы с реальной скоростью делали это так. Но лучше ли будет создавать новые адаптеры для таблиц каждый раз?
Если да, то существует уже существующий паттен, чтобы справиться с этим?
class Order
{
public int Id {get; private set;}
public string CustomerEmail { get; set; }
public SaleLocaion SalePoint { get; set; }
public Order(int orderId)
{
using (var ta = new OrdersTableAdapter())
{
using (var res = ta.GetDataById(orderId))
{
if (res.Count == 1)
{
var row = res.First();
Id = row.Id;
CustomerEmail = row.Email;
SalePoint = new SaleLocaion(row.SaleLocationId);
}
}
}
}
}
class SaleLocaion
{
public int Id {get; private set;}
public string Name { get; private set; }
public SaleLocaion(int locationId)
{
using (var ta = new SaleLocationAdapter())
{
using (var res = ta.GetDataById(locationId))
{
if (res.Count == 1)
{
var row = res.First();
Id = row.Id;
Name = row.Name;
}
}
}
}
}
Не имеет значения, будете ли вы их повторно использовать или нет. Они реализуют IDisposable
но только потому, что они наследуют от Component
который реализует IDisposable
из-за возможностей перетаскивания DataSet. Но им не нужно распоряжаться ими по той же причине, почему DataSet
и DataTable
реализуют IDisposable
но на самом деле их не нужно удалять.
Конструктор или инициализация поля также очень дешевы, поскольку все поля являются null
а конструктор содержит только:
public OrdersTableAdapter() { // an examplary auto-generated table-adapter constructor
this.ClearBeforeFill = true;
}
Поэтому выберите наиболее читаемый и отказоустойчивый подход.
DataTable
, да.