Лучший шаблон разработки для соединений таблицы базы данных
Рефакторинг для простоты, введя больше локальных переменных, которые указывают значение каждого выражения. Это трудно для нас, не имея представления о том, что означают a, b и p.
9 ответов
Active Record в Rails моделирует это, разрешая объекту Customer иметь_many Accounts, что в основном переводится в коллекцию объектов Account, которые, в свою очередь, имеют набор функций. Отношения могут быть двунаправленными, поэтому каждая модель AR может «знать» о своих отношениях, в зависимости от ваших потребностей.
Я думаю, что для объекта нормально знать другие таблицы, поскольку такие отношения являются фундаментальными как для объектно-ориентированных, так и для объектно-ориентированных приложений. СУБД / SQL.
В C # / Linq to SQL это будет примерно так. (Я предполагаю, что на самом деле существует таблица поиска типов функций, так что у вас есть стандартный список типов ваших функций, а затем их связь с учетной записью отдельно, поэтому FeatureTypeId будет вашим значением FK, может быть выбрано из раскрывающегося списка list или что-то в этом роде.)
// or whatever data type your keys are in
public IEnumerable<Customer> getCustomersForFeature(int featureTypeId)
{
return from feature in dbContext.Features
where feature.FeatureTypeId == featureTypeId
select getCustomer(feature.Account.Customer.Id);
}
На каком-то уровне ваш DAO / BAO должен знать об отношениях между вашими объектами, поэтому тот факт, что это отношения дедушки и бабушки, не должен быть слишком страшным.
Что касается того, где они принадлежат в вашей структуре BAO аргумент, вероятно, может быть любым. Я бы, наверное, поставил это на Клиента, так как это, в конечном счете, то, к чему я пытаюсь добраться.
Изменить: Как указал Тоби, отношения двунаправленные; снова в Linq, вы можете пойти и другим путем:
Как правило, моделируйте данные в соответствии с возможностями базы данных SQL, которую вы используете. Игнорируйте ORM, Mappers и т. Д.
Если у вас есть хорошая модель данных, и если ActiveRecord или DAO не будут обращаться к ней так, как вы хотите, то обойдите их, написав SQL.
Предполагается, что реляционное сопоставление объектов сделает программировать с базами данных проще, но из-за различий между моделями иногда проще сразу перейти к SQL.
Согласовано с GalacticCowboy, что ORM позволяет отделить детали отображения классов базы данных от объектов ориентированные запросы. Просто хочу предоставить пример для java hibernate orm - есть несколько способов определить сопоставления ассоциаций , и следующий объектно-ориентированный запрос HQL отлично работает над всеми из них
выберите c из Customer c left join c .accounts левое соединение a.features f, где f.name = 'cool'
Обратите внимание, что 'Customer' - это имя класса здесь, а 'c.accounts' , ' a.особенности '
Хотя объект Object to Realtional отлично подходит для обслуживания таблиц типа CRUD, я не нахожу ничего лучше реального SQL, когда дело доходит до таблиц сложных запросов.
Модель ORM - это слишком далеко абстракция.
I think this is classic problem ( at least for me ) , where you want to represent your data model in your application. According to my own experience there is always akward sitution like you described. Мое решение очень похоже на ответ выше. Сделайте простой класс, который один в один с вашей таблицей, и если эта таблица имеет отношение к другой таблице, тогда сделайте как свойство в вашем классе.
И по поводу вашего высказывания: « Я хочу выполнить поиск одним нажатием. ', я думаю, вам следует написать собственный SQL-запрос или, возможно, использовать LINQ.
Требования могут решить это за вас. Либо к сроку, вашей культуре работы или требованиям вашего проекта. Ваш крайний срок может указывать «код для инструментов» и сокращать функции. Вашим сотрудникам может потребоваться «никаких новых библиотек или режимов отказа». В моем собственном окружении вы бы услышали, как я рассказываю эту историю:
"... не годится вводить новые библиотеки ORM, поэтому их нет. Сроки означают, что я не должен начинать учить себя, как создавать Представления SQL. Моя рабочая культура подсказывает мне, что нужно делать это быстро. Моя архитектура вопит при сериализации целых таблиц, и мои требования к производительности указывают на то, что я не должен кэшировать какие-либо из этих данных ... "
Представления SQL могут предоставить хороший способ абстрагируйте соединения от ваших объектов, и может позволить вам изменять схему более независимо от кода вашего приложения. Тем не менее, обновление представлений очень сложно, в зависимости от вашей базы данных. Если переносимость БД важна, это, вероятно, очень сильно повлияет на ваш дизайн.
Вы можете найти гармонию с гибридным подходом. Если вы используете шлюз таблиц, нет причин рабски агрегировать его в каждое представление таблицы на уровне приложения. Почему бы не использовать шлюзы таблиц или активные записи для обновления элементов в области таблицы, а также пользовательские классы, которые работают с запросами, ориентированными на представление?
нет причин рабски агрегировать его в каждое представление таблицы на уровне приложения. Почему бы не использовать шлюзы таблиц или активные записи для обновления элементов в области таблицы, а также пользовательские классы, которые работают с запросами, ориентированными на представление? нет причин рабски агрегировать его в каждое представление таблицы на уровне приложения. Почему бы не использовать шлюзы таблиц или активные записи для обновления элементов в области таблицы, а также пользовательские классы, которые работают с запросами, ориентированными на представление?В Модельно-ориентированном проектировании у вас есть логические Сущности в вашем приложении, и эти Сущности могут отображаться в несколько таблиц в физической базе данных. Конечно, вам нужно запустить более сложный SQL, чтобы получить полную сущность, и класс Model - это место, где реализуются эти отношения.
Я думаю, что ActiveRecord и им подобные можно использовать для простых запросов к одной таблице, но пытаться принудительно использовать эти шаблоны для сложных запросов слишком сложно. К счастью, у нас уже есть краткий предметно-ориентированный язык, который вы можете использовать для задания сложных запросов: SQL.
Итак, в вашем классе Model у вас будут методы для выполнения логических задач уровня приложения, такие как getCustomersForFeature () . В коде этого метода вам следует написать конкретный запрос либо с помощью методов ActiveRecord, либо с помощью прямого SQL, если необходимо. Таким образом, конкретный проект вашей базы данных инкапсулируется в одном месте, в классе Model.
Это означает, что нам нужно разорвать связь между моделью и таблицей. Объектно-ориентированная связь между моделью и классом ActiveRecord не IS-A - это HAS-A (или имеет-многие).
На ваш комментарий: Итак, что у нас Модель? Если ваше приложение в первую очередь должно работать с клиентами как с сущностью и рассматривает функции как более или менее атрибут клиентов, тогда да, ваша модель будет клиентами, и она скроет тот факт, что функции хранятся в отдельной таблице в базе данных. . Модель клиентов будет внутренне использовать либо ActiveRecord, либо простой SQL для сбора необходимых данных, чтобы обеспечить полное представление о сложном объекте, являющемся клиентом, с его связанными многозначными атрибутами.
Но что, если вашему приложению также необходимо напрямую работать с функциями? Например, экран администратора, где вы можете получать отчеты по функциям или создавать новые функции. Тогда было бы неуклюже получать доступ к функциям через модель клиента. Значит, вам все-таки понадобится модель Features. Только у него будут разные методы для реализации операций, которые вам нужно делать с функциями.
Каждый класс модели должен предоставлять API только того, что вам нужно сделать с этой моделью . Не нужно даже быть симметричным. Тот факт, что ваша модель «Клиент» может получать всех клиентов, у которых есть данная функция, не обязательно означает, что ваша модель функций должна получать все функции для данного клиента. Следуйте правилу YAGNI .
Но после того, как вы создали модель клиента и модель функций, не приводит ли это к дублированию логики, которая знает о взаимосвязях между таблицами? Да, может. Это одна из многих проблем, подпадающих под действие объектно-реляционного несоответствия импеданса .
Может ли это привести к дублированию логики, которая знает о взаимосвязях между таблицами? Да, может. Это одна из многих проблем, подпадающих под действие объектно-реляционного несоответствия импеданса . Может ли это привести к дублированию логики, которая знает о взаимосвязях между таблицами? Да, может. Это одна из многих проблем, подпадающих под действие объектно-реляционного несоответствия импеданса .I have spent some more time reading around the subject (including the Domain Driven Design mini-book referenced in Bill's answer). There is an Aggregate concept in that book, which most closely represents what I am trying to achieve; the Customer encapsulates and controls access to the Account and Feature. If we stick with the Domain Driven Design approach we could use a Repository to control retrieval of the Customer, and it seems to me that this is where knowledge of the database structure would be encapsulated.
I also had another look at my copy of Patterns of Enterprise Application Architecture, and while it seems that the ActiveRecord pattern is intended for a direct mapping of class to database table, if you chose not to follow the Repository approach from DDD then Data Mapper would be suitable for a composite mapping.
Thanks all for your contributions. I have voted up the answers that contributed to this conclusion. As this may not be the last point in this discussion, I have flagged this answer as Community Wiki.