Создание приложения базы данных REAL с использованием Datasnap

Я построил обширное 2-уровневое приложение в D2010, используя ADO и devexpress. Я хочу обновить это, чтобы использовать Datasnap в основном для обеспечения HTTPS-связи, а не только TCP / IP для уязвимого сервера SQL. Я следовал всем учебникам по Datasnap, которые смог найти. У меня есть Delphi Кэри Дженсена в глубине: ClientDatasets. Все хорошо и хорошо, но примеры довольно бесполезны, потому что в приложении REAL для баз данных сетки заполняются объединением нескольких таблиц и почти никогда из одной таблицы. Это устраняет возможность автоматического разрешения наборов клиентских данных сразу. Даже предложенные обработчики beforeupdateevent не будут работать в приложении datasnap, поскольку БД доступна только для сервера datasnap. Поэтому мне кажется, что мне нужно создать метод на сервере datasnap для КАЖДОЙ вставки / обновления, в которой я буду нуждаться, а затем предоставить эти методы клиенту и вызывать их от клиента в соответствии с требованиями, чтобы запросить сервер datasnap для выполнения требуемого обновление / вставки. Это похоже на большую работу!

Есть ли более простой способ реализовать связь https с SQL Server?

О, если вам интересно, приложение уже является псевдо-трехуровневым, поскольку сетки привязаны к TdxMemData, а не напрямую к TADOQueries. Я сам выполняю все операции вставки / обновления так же, как если бы я использовал TClientdatasets.

sql-server,delphi,https,ado,datasnap,

4

Ответов: 2


против 6 принят

Если вы считаете, что ваша база данных уязвима, подумайте дважды об использовании D2010 Datasnap. Это очень, очень уязвимо. Не обманывайте себя HTTPS, все еще не хватает многих частей, чтобы полностью защитить канал. Например, когда вы используете Datasnap, встроенная проверка подлинности Windows на сервере SQL (на основе Kerberos ...) исчезает.

Для полного объяснения смотрите: Почему Datasnap 2010 является игрушечной библиотекой . Это, конечно, мое личное мнение , но оно основано на моем опыте использования Midas / Datasnap начиная с Delphi 3 и моей текущей работе в области ИТ-безопасности.

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


[Обновление 2016 года: DataSnap в 2016 году еще более печально отстал с точки зрения безопасности и возможностей, чем это было, когда был написан этот вопрос. Я вообще не рекомендую его использовать в любых новых проектах.]

DataSnap - это решение проблемы построения многоуровневых (трех и более) приложений. Непосредственное подключение к SQL через Интернет из толстого клиента, который содержит всю бизнес-логику в клиенте, имеет много понятных проблем, в том числе тот факт, что изменения бизнес-логики требуют немедленного обновления ВСЕХ ваших клиентов. Улучшение среднего уровня (изменение бизнес-логики), находящееся внутри логики промежуточного уровня (или другой) привязки данных, распространяется не на каждого клиента. Клиенты тоньше и содержат меньше бизнес-логики. Во-вторых, хорошо разработанный «API» привязки данных, который вы создаете самостоятельно, только подвергает вас риску, который вы создаете сами, а не подвергает вас всему набору уязвимостей MS SQL.

Честно говоря, потеря аутентификации Kerberos от вашего толстого клиента не является причиной для отказа от идеи среднего уровня. Я совсем не понимаю точку зрения Лдсандона. Поддерживает ли он двухуровневую архитектуру приложений, которая подключается к клиентам через Интернет или локальную сеть и которая содержит всю бизнес-логику, как «более безопасную», чем многоуровневое приложение?

Неявный вопрос, предложенный вашим заголовком, не подлежит обсуждению и не определен. Что значит «настоящий»? Во многих отраслях промышленности используются двухуровневые «толстые» клиенты в собственных корпоративных локальных сетях. Многие считают полезным использование промежуточного уровня в своей собственной локальной сети, а многие считают, что внешние приложения, работающие через Интернет, определенно НЕ ДОЛЖНЫ выходить за пределы SQL-соединения с толстыми клиентами, и поэтому они предоставляют своего рода «веб-метод». (SOAP, REST + JSON и т. Д.) Архитектура. Было тщательно отмечено, что Data-Snap не является чисто «RESTful» архитектурой, но она использует JSON и во многих отношениях является REST-полной по дизайну, хотя и не полностью.

Если вы не понимаете проблему, для решения которой был создан DataSnap, легко подумать, что DataSnap бесполезен или (альтернативно и в равной степени ошибочен) в некотором роде серебряной пули. Он существует для определенной цели, которую многие люди находят полезным для своих нужд в области развития. Если вы намереваетесь взять на себя работу по созданию среднего уровня, DataSnap сделает это проще, чем сделать это на 100% как «сверните свой средний уровень», но это больше работы, чем отсутствие среднего уровня.

SQL-сервер, Дельфы, HTTPS, лукаво, DataSnap,
Похожие вопросы