Должен ли я иметь один класс для каждой базы данных, которую я использую?

Во-первых, позвольте мне объяснить, что я делаю. Мне нужно взять заказ, который разделен на разные базы данных, и распечатать этот очень большой заказ. Что мне нужно из заказов - это около 100 столбцов из разных баз данных. То, что я делал, - это запрос с объединением и присвоение всех значений столбца переменной в моем одном большом классе Order. Это стало проблематичным. Я задаюсь вопросом, вместо того, чтобы иметь один класс, который состоит из приблизительно 100 участников, которые составляют заказ. Должен ли я иметь только один класс для каждой базы данных, которую я использую, и затем работать с этим?

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

14.12.2008 04:02:00
Ваш заголовок не был полезен. Я не понимаю ваш вопрос, но я угадал название замены.
Jay Bazuzi 14.12.2008 06:10:38
Являются ли базы данных, которые вы загружаете, одного типа, например, SQL Server, Oracle, Interbase и т. Д.? Или все разные?
Jayden 14.12.2008 06:53:16
6 ОТВЕТОВ
РЕШЕНИЕ

Я иду против структуры здесь, но я бы сказал, что лучше сохранить этот объект в наборе результатов и сохранить соединение в базе данных.

Для бизнес-логики «заказ» - это, как правило, единое связное понятие (по крайней мере, именно так вы начали его формировать). Может ли тот факт, что он сопоставлен с несколькими таблицами (или базами данных), быть артефактом сбора данных? Я хотел бы задать себе эти вопросы, прежде чем разбить его:

  • Есть ли ощутимые преимущества при составлении заказа из других объектов?
  • Атрибуты имеют различную мощность? То есть, некоторые за заказ и другие за позицию?
  • Можете ли вы повторно использовать существующий код для составных объектов?
  • Вы включаете какое-то другое взаимодействие, которое легче сделать с несколькими объектами?

Если вы не ответите «да» ни на один из этих вопросов, держу пари, что ваш код будет более простым и более читабельным, если он будет работать только с порядком в качестве атомарного объекта и позволит базе данных скрыть сложность того, откуда он поступает ( Вы могли бы даже использовать представление для этого).

Само по себе количество атрибутов обычно не является причиной для разрушения интерфейса. Но, если сложность (или размер) самого объекта заказа вызывает у вас недостаток, вы можете попытаться упростить его внутренне, чтобы использовать какой-то универсальный метод доступа, такой как:

private object GetOrderAttribute(string attributeName){
    // use a data structure (like a hash table) to store and access internally
}
...
output("Quantity: " + GetOrderAttribute("quantity"));
// etc.

Еще одно замечание: хотя производительность редко должна быть вашей начальной заботой при проектировании логической системы, большинство случаев, связанных с объединением таблиц базы данных, будет работать лучше, если база данных выполнит объединение, поскольку СУБД может использовать индексы и другие механизмы для эффективного выполнения объединения и предотвращения загрузки. страницы с диска, которые не нужны. Может быть, все ваши индивидуальные запросы тоже это делают, но обычно это то, что база данных может выполнять на порядок эффективнее, чем код бизнес-логики. (Конечно, если соединение выходит за физические границы базы данных, это преимущество может быть потеряно.)

0
14.12.2008 17:39:46

Это действительно звучит так, как будто ты предпочитаешь меня. Как бы вы предпочли работать с ним? Будет ли вам легче работать с ним как с отдельными объектами C #, или вам будет легче работать с ним как с несколькими таблицами SQL?

0
14.12.2008 04:10:30
Я думал, что будет проще, чем у меня, но сейчас это кажется проблематичным из-за того, как спроектированы некоторые отношения с базой данных.
jumbojs 14.12.2008 04:24:33

почему бы просто не загрузить данные из отдельных БД inidividuallly?

Например, ваш конструктор для объекта Order будет выглядеть так:

Method New Order(orderId) {
   Get Database 1 Details
   Load Details into appropriate Variables
   Get Database 2 Details 
   Load Details into appropriate Variables
   Get Database **N** Details 
   Load Details into appropriate Variables
}

это упрощает поддержку sql, который касается отдельных БД, и у вас не будет дюжины различных классов для каждой БД.

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

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

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

1
14.12.2008 04:31:20

Я бы порекомендовал объектно-ориентированное решение для этого. Предположительно ваша база данных спроектирована с таблицами, которые представляют логические группы данных. Каждая из этих таблиц, вероятно, может быть сопоставлена ​​с классом в вашей системе, хотя в некоторых случаях это может быть несколько таблиц, составляющих объект, или может быть несколько классов, на которые таблица отображается с использованием подклассов. Если вам нужно отобразить данные из нескольких таблиц - скажем, список заказов с некоторыми данными от клиента, связанными с заказом - тогда вы можете использовать представления, объединения или хранимые процедуры для создания объекта класса представления, который представляет выбранные данные в представлении / присоединиться / sp.

По сути, я описываю N-уровневую архитектуру данных, где у вас есть низкоуровневый уровень доступа к данным, который обрабатывает данные с ориентацией SQL - таблицы, представления, хранимые процедуры. Выше этого может быть общий уровень объектов, который имеет дело с общими объектами данных и взаимодействует с уровнем доступа к данным для хранения / извлечения объектов из базы данных. Наконец, над этим у вас есть строго типизированный уровень бизнес-объектов, где ваше приложение работает с классами, которые семантически связаны с вашим приложением - заказами, клиентами, счетами и т. Д. Существует множество различных шаблонов для реализации этого типа общей архитектуры, и вам следует изучить несколько, чтобы увидеть, что подходит вашему приложению нуждается в лучшем.

Лично я думаю, что структурирование вашего приложения для работы с объектами в контексте вашего домена, а не просто как с табличными данными, улучшит ваш код. Это должно улучшить понятность и ремонтопригодность. Вы сможете инкапсулировать поведение внутри классов вашего домена, а не распространять его по всему приложению. Конечно, это предполагает, что вы следуете передовым методам проектирования, но использование ОО дизайна будет способствовать этому. Отделение бизнес-логики и логики данных от логики отображения также сделает ваше приложение намного более тестируемым, как и разбивка монолитных классов на более мелкие, более сфокусированные классы, которые взаимосвязаны.

2
14.12.2008 04:58:49

Я хотел бы рассмотреть возможность создания класса для обработки данных в каждом отдельном хранилище данных.

Затем я хотел бы рассмотреть использование шаблона, что-то вроде Facade для группировки этих подсистем вместе. Ищите в Интернете «Шаблоны проектирования» и «Фасад» для получения дополнительной информации. Затем фасад может учитывать любое конкретное взаимодействие между данными в отдельных хранилищах данных.

Для меня гораздо проще поддерживать код, который логически сгруппирован, и для меня имеет смысл иметь отдельные классы для отдельных хранилищ данных.

0
14.12.2008 06:44:01

Одним из элегантных и простых подходов к решению этой проблемы является шаблон Active Record:

http://en.wikipedia.org/wiki/Active_record_pattern

Конечно, это может быть неосуществимо в каждом сценарии. Он также может быть интегрирован с другими шаблонами, как подразумевается в других ответах. Я тот, кто считает, что вы столкнетесь с компромиссами независимо от того, какой подход вы выберете. Всего наилучшего!

1
14.12.2008 07:49:05
Я не видел ни одного ранее такого имени, и этим я пользуюсь все время. Спасибо!
Ian Varley 14.12.2008 17:03:43