Каково различие между транзакцией SQL на уровне хранимой процедуры и один на уровне SqlConnection?

Я лично предпочитаю вариант (3) в качестве решения. Он используется почти на всех сайтах моего бывшего (фамилии) работодателя. Это означает, что вы можете получить некоторых разработчиков интерфейса, которые знают все о Javascript, особенностях браузера и еще много чего, чтобы закодировать ваш интерфейс. Им нужно знать только «curl xyz, и вы получите немного json», и они уходят.

Тем временем ваши тяжелые бэкэнды могут кодировать поставщиков Json. Этим ребятам вообще не нужно думать о представлении, а вместо этого беспокоятся о нестабильных бэкэндах, тайм-аутах, изящной обработке ошибок, пулах соединений с базами данных, потоке, масштабировании и т. Д.

Вариант 3 дает хорошую, прочную трехуровневую архитектуру. Это означает, что материал, который вы выплевываете из внешнего интерфейса, оптимизирован для SEO, может быть приспособлен для работы со старыми или новыми браузерами (и с отключенным JS), и все же может быть Javascript на стороне клиента, если хотите (можно делайте что-то вроде обработки старых браузеров / googlebot со статическим HTML, но отправляйте JS встроенные динамические приложения людям, использующим последний браузер Chrome или любой другой).

Во всех случаях, которые я видел в Варианте 3, это была пользовательская реализация некоторого PHP, который не особенно переносим между проектами, не говоря уже о том, чтобы выходить на землю с открытым исходным кодом. Я предполагаю, что совсем недавно PHP, возможно, заменили на Ruby / Rails, но то же самое по-прежнему верно.

FWIW, $ current_employer мог бы сделать с вариантом 3 в нескольких важных местах. Я ищу хороший Ruby-фреймворк для сборки чего-либо. Я уверен, что смогу собрать воедино множество драгоценных камней, но я бы предпочел один продукт, который в целом предоставляет шаблонное, «скручиваемое», дополнительное аутентификация, дополнительное решение для кэширования с использованием memcache / nosql. Там я не могу найти ничего связного: - (