Улучшения дизайна классов доступа к данным и текстовым данным - PullRequest
Новая
       1

Улучшения дизайна классов доступа к данным и текстовым данным

0 голосов
/ 18 марта 2011

Я создаю небольшое приложение с интенсивным использованием данных с помощью Windows Forms. В основном проекте у меня есть папка, в которой хранятся мой DBML, а также классы данных для обеспечения CRUD-операций с базой данных. В настоящее время существует около 10 указанных классов данных.

Код в форме создает экземпляры бизнес-объектов и обращается к ним, чтобы выполнить всю работу. Эти бизнес-объекты выполняют вызовы к классам доступа к статическим данным.

Примером класса данных будет что-то вроде этого 

static class CustomerData
{
    public static IEnumerable<Customer> GetCustomersForRun(int runID)
    { 
         var db = new FooDataContext("connectionString");
         return db.Customers.Where(ri => ri.RunID == runID);
    }
}

Теперь, очевидно, есть несколько проблем с моим первоначальным дизайном, которые мне нужно решить.

1) Нехорошо иметь каждый статический метод для создания своего собственного DataContext. Это совсем не СУХОЕ.

2) Поскольку я полагаюсь на ленивую загрузку, я не могу обернуть свой DataContext в оператор использования.

Несколько разных идей, которые мне нужно решить, это

1) Избавьтесь от статических методов и вместо этого создайте абстрактный базовый класс доступа к данным, который может создавать экземпляр моего DataContext.

2) Пусть каждый бизнес-объект создает свой собственный DataContext и передает его в статические методы классов доступа к данным.

Пример сигнатуры метода будет тогда 

public static IEnumerable<Customer> GetCustomerForRun(DataContext db, int runID)

Мои конкретные вопросы

1) Я слишком усложняю это?

2) Обычно вы избавляетесь от своих объектов DataContext?

3) Какое из моих решений наиболее целесообразно? Если ни один из них, что вы рекомендуете?

1 Ответ

0 голосов
/ 18 марта 2011

1) Я слишком усложняю это?

Это действительно зависит от того, является ли ваше приложение очень маленьким, и шаблон в миксе может усложнить ситуацию, если просто использовать DataContextможет упростить понимание, а не помещать слой абстракции поверх linq в sql.

2) Как правило, вы избавляетесь от своих объектов DataContext?

Itбудет зависеть от вашей имплементации, если вы планируете передать IQueryable<T>, чтобы выполнить фильтрацию, упаковывающую блок using(){}, вызовет у вас горе.Поскольку linq to sql запускает запрос sql только тогда, когда вы делаете что-то, что вызывает GetEnumerator(), ваш контекст может быть удален, и ваш вызов не будет выполнен.

Conceder в этом примере: 

IQueryable<Table> GetStuff()
{
  using(var db = new DataContext())
  {
     return db.Tables.Where(i=>i.Id == 1);
  }
}

еслидругой метод, который вы попытаетесь сделать, GetStuff().Where(i=> i.Name == "Jon").ToList() вызовет сбой запроса, так как контекст уже удален.

Теперь, если вы этого не сделаете, вы можете получить силу IQueryable

IQueryable<Table> GetStuff()
{
  return db.Tables.Where(i=>i.Id == 1);
}

GetStuff().Where(i=> i.Name == "Jon").ToList() будет работать и позволит вам отфильтровать ваш запрос и отложить выполнение оператора sql до самой последней минуты.Более подробную информацию можно найти здесь .

3) Какое из моих решений наиболее целесообразно?Если ни один из них, что вы порекомендуете?

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

...