Создание НАСТОЯЩЕГО приложения базы данных с использованием Datasnap

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

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

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

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

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

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

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

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