Бизнес-объекты и динамические sql

Question

У меня была эта идея и моя первая реакция после того, как она была «Это отличная идея, но почему я никогда не видел/не слышал, чтобы она говорила раньше?» Поэтому я надеюсь, что вы скажете мне, есть ли какие-то рамки, которые уже делают это, или если есть какая-то причина, почему я должен ее избегать.

Идея состоит в том, чтобы создать базовый класс бизнес-объектов с методами динамической записи запросов CRUD sql на основе имени производного класса и его свойств (или псевдонимов, указанных в атрибутах).

Мое мышления является то, что когда-то я делаю это я мог бы просто создать новый класс, как так:

и мой класс клиентов, имеющий доступ к методам CRUD BusinessObjectBase, в будут сделаны.

Что-то нужно иметь в виду при ответе на это: Для этого вопроса меня очень интересуют цели проектирования, связанные с сокращением времени разработки и низким уровнем обслуживания, а безопасность составляет около 3 по шкале от 1 до 10. Другими словами, я не заинтересован в том, чтобы слышать ответы, говорящие мне, что я должен использовать хранимые процедуры для доступа к данным, потому что они более безопасны или что-то в этом роде.

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

Существуют ли какие-либо существующие рамки для этого или есть какая-то веская причина, почему я не должен?

Answer 1

Это было сделано раньше; много раз, много способов. Основная концепция, о которой вы думаете, называется «первой моделью». Вы можете сделать модель сначала в Entity Framework, NHibernate, Subsonic и многих других стилевых фреймах ORM. Еще одним воплощением этой линии мышления является LINQ-to-SQL, где LINQ знает, какие запросы нужно генерировать, независимо от того, хранились ли вы CRUD-процессы.

Перед тем, как ORM были основными, мы используем файлы кода (в наши дни кодированные в шаблонах стиля T4), чтобы написать, что вы описываете. Вся идея была основана на «соглашении», означающем, что если поле имеет идентификатор ID, тогда оно должно быть кластеризованным PK и так далее.

Отказ

С учетом сказанного, есть обратная сторона этой линии мышления. В вашем типичном веб-приложении (или вставьте в него стиль приложения) у вас есть три уровня для работы с клиентом, средой и БД. При разработке модели/кода вы фактически игнорируете один из трех уровней. Современное оборудование стало достаточно быстрым, чтобы вы могли сделать это для большинства сайтов. Когда ваш сайт растет в объеме & сложности, однако вы часто окажетесь вокруг этой автоматической настройки для самых сложных/часто используемых сценариев.

В любом случае, надеюсь, что это поможет.