#database #delphi #dbexpress #datasnap
#База данных #delphi #dbexpress #datasnap
Вопрос:
Если мой вопрос неясен, пожалуйста, помогите мне улучшить его с помощью комментариев.
Я новичок в Delphi и dbExpress, и я только знакомлюсь с классами TSQLDataset, TDataSetProvider, TClientDataSet и TDataSource.
Проект, над которым я работаю, использует эти компоненты странным для меня образом. Существует огромный модуль данных, который содержит множество квартетов классов, описанных ранее. Я предполагаю, что есть лучшие (и более модульные) способы сделать это. DataSnap используется только для размещения этого модуля данных в серверном приложении, поэтому клиенты получают доступ к данным через него.
Итак, позвольте мне попытаться объяснить некоторые из моих сомнений:
- Какова роль каждого из этих классов? Я прочитал документацию, но не могу получить практическое представление по этому вопросу (особенно о TDataSetProvider).
- Какие классы должны быть в модуле данных, а какие в моих формах?
- Возможно ли создать промежуточный уровень для абстрагирования моей бизнес-модели от настройки моей базы данных (возможно, создание функций, которые возвращают неизменяемые наборы данных?)?
- Если да, разумно ли использовать DataSnap для этого?
Извините, если я недостаточно понятен. Заранее спасибо.
Ответ №1:
Компоненты
TDataSource — это мост между элементами управления с поддержкой данных и набором данных (потомок TDataSet), из которого они должны получать свои значения.
TClientDataSet является одним из таких наборов данных. TClientDataSet может использоваться изолированно, например, для доступа к данным, содержащимся в файлах xml, но также может быть подключен к TDataSetProvider.
TDataSetProvider — это мост между TClientDataSet в памяти и фактическим набором данных, который берет свои данные из базы данных через какой-то драйвер. При разработке клиент-сервера вы обычно увидите TRemoteDataSetProvider (имя может быть другим, я не так часто работаю с этими компонентами), который устраняет разрыв между клиентом и сервером.
TSQLDataSet — это фактический набор данных, получающий свои данные из некоторой базы данных.
Мне было бы странно видеть этот квартет в одном исполняемом файле. Я бы ожидал, что TSQLDataSet на стороне сервера подключен к части счетчика TRemoteDataSetProvider. Однако я предполагаю, что со встроенной базой данных это может быть способом поддержки модели портфеля, в которой TClientDataSet действительно полезен (TClientDataSet очень мощный, это только одна из его сильных сторон.)
Единый модуль данных
Ой. Один огромный datamodule — это ленивое программирование или результат неправильных представлений о том, как использовать datamodules. Совершенно нормально иметь один модуль данных, который «размещает» соединение с базой данных, которое затем используется различными другими модулями данных, которые более тесно ориентированы на аспекты приложения.
Абстракция домена
Что касается абстрагирования вашей бизнес-модели, dbexpress и datasnap действительно не должны быть нигде в вашей бизнес-модели. Они должны быть частью вашего уровня данных.
TDataSource, TClientDataSet и пользовательские потомок (ы) TDataSetProvider можно использовать для использования возможностей элементов управления с учетом данных в пользовательском интерфейсе, сохраняя при этом пользовательский интерфейс отдельно от бизнес-модели. В этом случае пользовательский TDataSetProvider будет связующим звеном между клиентским набором данных и коллекциями и экземплярами на уровне домена.
Несмотря на это, я все равно ожидал бы увидеть отдельный уровень данных, используя TRemoteDataSetProviders или прямых потомков TDataSet (например, TSQLDataSet) для предоставления данных на уровне домена.
Упомянутый вами единый огромный модуль данных может быть частью этого уровня данных, а клиентские наборы данных предоставляют бизнес-уровень со своими данными. Поскольку вы также упоминаете TDataSource как часть общего квартета, приложение, вероятно, было разработано с учетом RAD-данных, где элементы управления пользовательского интерфейса в основном подключены непосредственно к столбцам / таблицам базы данных.
Если вы хотите преобразовать это приложение в более многоуровневую архитектуру, действуйте осторожно и медленно. Сначала познакомьтесь с текущей архитектурой и изучите ее достаточно хорошо, чтобы увидеть влияние, которое окажет такое преобразование. Ссылки, предоставленные Serg, безусловно, помогут вам в этом. Павел Гловацки много писал о DataSnap.
Комментарии:
1. Итак, в моем клиентском приложении я бы видел только поставщиков наборов данных, наборы данных clien и источники данных? И еще: являются ли модули данных хорошим местом для реализации отдельного уровня данных? Ваш ответ отличный, и я думаю, что он может стать очень хорошей отправной точкой для людей, желающих разрабатывать приложения для баз данных на Delphi. Я сам прочитал документацию, но до сих пор не мог собрать части вместе.
2. @haole: да, это те компоненты, которые я ожидал бы увидеть в клиентском приложении. Datamodules подходят для реализации отдельного уровня данных. Однако они вам не нужны. Я бы просто использовал «обычные» модули и создавал экземпляры компонентов во время выполнения, подключая обработчики событий по мере необходимости с помощью кода (несколько вопросов об этом здесь, на SO). У него есть дополнительное преимущество, не имеющее dfm datamodule и всех проблем с синхронизацией / слиянием, связанных с файлами dfm и системой управления версиями.
Ответ №2:
Проект, над которым вы работаете, представляет собой многоуровневое приложение базы данных Delphi
Ваш вопрос слишком широк для SO и вряд ли на него можно ответить в его нынешнем виде — вы должны научиться понимать базовую архитектуру.
Вы можете начать с видеоурока Павла Гловацкого:
Комментарии:
1. Эти учебные пособия просто показывают мне, как разместить мою базу данных в другом приложении с помощью DataSnap. Это не абстракция концепции: пользовательский интерфейс по-прежнему очень тесно связан с базой данных.