Шаблон доступа к данным для нетрадиционного макета базы данных

Question

Я начал обслуживать приложение, которое поставляется с большой базой данных, которая частично не нормализована / довольно грязная.Много повторяющихся данных и несколько таблиц с множеством полей (более 30).Например, у меня есть таблица с именем Orders, которая содержит множество полей.Я бы пошел и разделить эту таблицу, но изменения в макете базы данных не допускаются.Теперь, если я, например, придерживаюсь шаблона репозитория, я считаю, что должен создать сущность Order и методы CRUD для нее.Проблема в том, что бизнес-логика почти никогда не требует загрузки / обновления всего объекта заказа, а только его подмножества.Это составило бы множество сущностей (таких как FullOrder, OrderMetaInfo, OrderProcessingDetails и т. Д.).

Мой вопрос заключается в том, как лучше всего справиться с подобным беспорядком в базе данных?Я думал о создании простого класса с именем Orders. Объекты, упомянутые ранее как POCO, имеют методы UpdateOrderMetaInfo () или GetOrderProcessingDetails ().Это кажется довольно хорошим способом, пока вы не начнете думать о том, что есть две таблицы: одна - «Заказы», ​​а другая - «Архивные заказы» (и нет, поля не идентичны, но очень похожи - даже не спрашивайте).Кажется, я буду работать с огромным количеством дублирующегося кода.Теперь я начинаю думать о написании действительно простого класса доступа к базе данных, где вы передаете ручной SQL-запрос и получаете набор записей, как в старые добрые времена.У вас есть идея получше, чем эта?

Факты и ограничения: Это база данных Sql, и проект написан на C #.Существует другая система, использующая ту же базу данных, поэтому изменение макета базы данных - это , а не вариант.Использование EF или любого стороннего продукта для доступа к данным - тоже вариант , а не .

Извините за очень длинный пост и спасибо за ваш отзыв.

Answer 1

Почему бы вам просто не использовать установщики свойств, чтобы фактически "пометить" то, что необходимо обновить.

Например, пользователь может сделать

Order.Client = "Jorge";
Order.Price = 300;
Order.Provider = "Microsoft";

тогда ваш сеттер будет выглядеть как

public string Client{
set
{
  mClient = value;
  ModifiedFields.Add("ClientField");
}

и, наконец, ваш метод Update на основе информации ModifiedFields решит фактический запрос, который необходимо выполнить для обновления измененных полей.

Чтобы фактически получить данные, вы можете просто использовать общий метод GetOrder (), если запрос не такой медленный, или ... если он действительно достаточно весит, чтобы убить вашу производительность, чтобы получатель для каждого свойства извлек необходимую информацию для заданное подмножество данных, либо с помощью политики кэширования, либо путем предоставления GetLastValue свойству.

Пример:

public class DBField<T>
{
  private DBCommand getCommand;

  public T Value {get;set;}
  public T GetLastValue()
  {
     // Execute getCommand here
  }

  public DBField<T>(DBCommand GetCommand)
  {
    this.getCommand = GetCommand;
  }
}

Затем пользователь сделает:

string Client = Orders["Id"].Client.GetLastValue();

Answer 2

Это похоже на проблему, с которой сталкивался любой другой разработчик ... это требование НЕ менять базу данных - отстой, но если вам придется придерживаться этого, я могу поделиться некоторыми вещами, которые я сделал, с очень близким приложением, которое яработал с ... Раньше у меня были объекты DAO, которые имели текстовый текст Linq To Sql.Я согласен с тем, что сущность Order не нужно загружать полностью, но способ, которым мы ее обошли, заключался в использовании некоторых полезностей linq to sql, как описано здесь:

http://www.sidarok.com/web/blog/content/2008/05/02/10-tips-to-improve-your-linq-to-sql-application-performance.html

Обратите особое внимание на параметры загрузки данных и скомпилированные запросы.

Я должен сказать вам, что это не лучшее решение, но выполнимое, и вы можете сохранить свой код красивым и чистым с помощью Linq to Sql, которыйне что-то очень сложное ... надеюсь, это поможет.

Answer 3

Я в похожей ситуации на работе.

То, как я справился с этим, заключалось в создании новой базы данных, которая состоит только из представлений о существующей путанице в базе данных.Наши приложения затем используют представления для всех операций.