Здравствуйте, Ziaw, Вы писали:
Z>Суть у них одна.
Верно, "суть" одна. К сожалению, одной только "сути" недостаточно.
Теоретически, современные движки RDBMS позволяют спроектировать приложение как набор view c instead of триггерами, которые и будут реализовывать нужную нам бизнес-логику.
Тогда клиент сможет работать с ним исключительно в терминах CRUD-операций, и фреймворки, заточенные на публикацию ER-модели в виде REST или GUI, будут уместны.
На практике эта идея упирается в ограничения на исполняемый в рамках СУБД код. Поэтому, как правило, в СУБД лежат достаточно тупые таблицы с минимумом триггеров, а ограничения целостности вводятся не для обеспечения бизнес-логики, а для семантических оптимизаций.

REST-интерфейс выставляет наружу некоторую специальную информационную модель. Она достаточно нетривиальным образом ложится на модель данных.
Обычно в разговорах об архитектуре под CRUD понимают достаточно узкую штуку: это набор методов по манипуляции именно данными в таблицах.
То есть Update здесь — это просто Update, сохраняем атрибуты одной Entity. В Rest update — это PUT или PATCH; за ними мы ожидаем увидеть какую-то бизнес-логику.
Z>Откуда взялся мобильный клиент в теме про веб-фреймворки? Я говорил, что мне не нравится в веб-клиенте бизнеса, который, похоже, делался по принципу — засунем все в одно SPA.
Эмм, из обсуждения того, как устроены удобные для пользователя приложения.
Ещё раз поясню: мобильные приложения как раз демонстрируют современные достижения юзабилити.
Во-первых, потому что там нет адского легаси в стиле "отцы терпели — и ты потерпишь", а во-вторых, потому что мобильник сам по себе очень неудобен. И "традиционные" подходы на нём сосут. Достаточно попробовать открыть этот сайт на айфоне, чтобы получить наглядный пример.

То есть когда мы пишем мобильное приложение, то мы вынужденно думаем не о том, как "выставить в гуе" список заказов, список адресов, список кредитных карточек, и что там ещё у нас может быть списком, а о том, какие действия выполняет пользователь. И пляшем от них. В хорошем десктопном приложении надо делать так же. Но примеров таких приложений — гораздо меньше, чем мобильных.

REST, который выставляется между клиентом и сервером, может быть устроен существенно по-другому, чем GUI. И, естественно, существенно по-другому, чем внутреннее устройство таблиц БД.

Вот теперь на первый план выезжают фреймворки, которые помогают мне строить серверную часть вот таких вот приложений.
Не нравится мобильный клиент альфа-банка — ок, давайте посмотрим на какой-нибудь booking.com или momondo. Там главное "окно" — это выхлоп "поискового запроса". Нет никакой таблицы в БД, которая бы соответстовала view "подходящие варианты размещения". Там есть несколько таблиц, и нетривиальная логика по извлечению из них данных.

Z>Нет, я пытаюсь понять, почему "нормальные" интерфейсы не дают мне делать то, что мне нужно.
Вы просто взяли пример "плохого" интерфейса Я же не говорю, что он хороший — он плохой.
Но в том, что он плохой, виноват точно не тот фреймворк, который они взяли.

S>>Эмм, вы вообще master-detail видели? Ну, чтобы убедиться, что мы об одном и том же говорим?

Z>Я устал уже от отсылок к delphi, mobile, тонкостей толкования REST. Давай вернемся к теме и разберемся, чем конкретно хороша и плоха динамика в веб-разработке.
Отлично, давайте.
Z>Не надо мне в каждом посте "тонко" намекать, что твое толкование REST, нормального интерфейса или master-detail чем-то лучше моего. Если что-то считаешь лучшим решением, приведи его, объясни его плюсы, будь готов ответить на вопросы, а все эти намеки свысока "вы вообще master-detail видели" задолбали.
Прошу прощения, если мой тон вас обижает. Я всего лишь пытаюсь убедиться в соответствии терминологии, чтобы обсуждение было конструктивным.

Z>Понятно. Очень спорно, но не по теме. По теме это укладывается в REST и сценарий PATCH заказа. И вполне нормально вписывается в идеологию RoR.
Отлично. Вот мне хочется понять — каким образом идеология RoR

Z>Возможно тебе хотели показать, насколько проще делаются банальные сценарии, потому, что показать что-то сложное за пять минут нельзя. А ты составил поверхностное суждение и теперь его отстаиваешь.
Не, я не отстаиваю. Я хочу разобраться в том, где я заблуждаюсь.

Z>Например, разве, делфи оказалась плоха, потому, что можно было бросить грид на форму? Между прочим это был прекрасный инструмент, который был вытеснен C# и .net, как языком так и платформой. Я сам в свое время перешел с радостью, надоело вручную управлять памятью и писать на паскале. Сам редактор форм там был ничуть хуже winforms, а во чем-то даже лучше.
Я тоже в своё время очень много написал на Delphi. Просто

Z>Точно так же я и на RoR ушел. Надоело вручную управлять парком велосипедов. Возможно есть приложения и бизнесы, в которых содержание этого парка оправдано, но мне не нравится аргументация в стиле: "отстутствие необходимости писать велосипед на каждый чих провоцирует нас не писать их совсем, это расслабляет и делает наши приложения неудобными для пользователей". Нужен велосипед — пишем. Преимущество RoR в том, что многое можно брать в готовом виде и кастомизировать ровно то, что нужно.

S>> Ничего странного в REST с "искусственными ключами" нету. И наличие привязки к ER не означает эквивалентность ER. Эта привязка может быть выполнена большим количеством разнообразных способов.

Z>Так в чем тогда проблема?
В том, что большая часть кода приложения — это преобразования данных из одной структуры в другую. В динамике это сводится к перекладыванию из одной хешмапы в другую. В статике — это преобразования типов.
И теоретически как раз статический контроль типов позволяет нам оперативно отслеживать некорректности этих преобразований. Я пока не могу понять, чем же динамика лучше.
Всё, что я услышал в качестве критики статики — "необходимость создавать и поддерживать бесчисленные DTO". Ну, так это справедливо только в том случае, если DTO нужно декларировать заранее и явно.
Современная статика копает в сторону автоматического вывода типов DTO вместо явного их описания.
То есть там, где в динамике мы в результате Select FirstName, LastName, DateDiff(Now(), BirthDate, Year) as Age получаем просто рекордсет, из которого надо доставать данные по именам, в статике мы получаем экземпляр анонимного типа со вполне определёнными типами FirstName, LastName, и Age. Что потенциально позволяет нам сразу же отлавливать несоответствия использования.
Z>Пусть будет PUT, мы опять ушли от темы. Где идемпотентно — PUT, где нет — POST. Если простое изменение данных, в сущность, если это операция — то в операцию. Как это относится к рельсам или .net?
Ок, вернёмся к теме. Каким образом нам рельсы помогают проверить корректность данных, приехавших в PUT?

Z>Насколько я понимаю, в этом плане все равно придется что-то изобретать для идемпотентности, хоть POST это будет, хоть PUT, задача программиста сделать идемпотентный обработчик не решается выбором глагола.
Выбор глагола подталкивает к решению. Когда мы реализуем PUT, то у нас уже есть resource id; и нам нетрудно реализовать if (newObject.Equals(existingObject)) return 200 Ok, чтобы пропустить весь блок бизнес-логики, связанный с изменением состояния (типа отправки письма "заказ принят" и прочих штук). Когда мы реализуем Post, то надо прямо отдельно думать о том, "а что если это не новая операция, а повторная отправка старой, которая потерялась".

S>>Ну, мне важнее всего код клиента. Потому что сервер — он один, а клиентов — много. С клиента реализовать корректную смену статуса через patch проще, чем через POST и прочее. Мне не надо прикапывать RequestID и прочее — вполне себе тупой клиент способен поддержать смену статуса, не приводя к ошибкам.

Z>Чем проще-то? Не могу понять. Ну кроме того, что не надо дополнительно документировать идемпотентность.
А что, одного этого мало? Даже тупой веб-клиент, который отправляет PUT, получит корректный результат при повторном нажатии на кнопку.

Z>Все остальное — тонкости понимания REST, предпочтения в UI, что там было в Delphi, идут параллельно теме и тоже совсем не конструктивно. Ты занял позицию гуру — кругом говно, читайте книги, там все рассказано. Я не просил совета, какие книги мне читать.
Можно и закруглиться. Я ожидал совета, какие книги мне почитать. Ну, или примеров про то, как RoR помогает. Вы приводите косвенные признаки — ваше приложение на рельсах проще, чем оно было бы на .Net.
Было бы интересно посмотреть на фрагмент RoR кода, который плохо перепишется на C#. Потому что без этого всё упирается в opinion и вкусовщину.

Здравствуйте, Ziaw, Вы писали:
Z>Суть у них одна.
Верно, "суть" одна. К сожалению, одной только "сути" недостаточно.
Теоретически, современные движки RDBMS позволяют спроектировать приложение как набор view c instead of триггерами, которые и будут реализовывать нужную нам бизнес-логику.
Тогда клиент сможет работать с ним исключительно в терминах CRUD-операций, и фреймворки, заточенные на публикацию ER-модели в виде REST или GUI, будут уместны.
На практике эта идея упирается в ограничения на исполняемый в рамках СУБД код. Поэтому, как правило, в СУБД лежат достаточно тупые таблицы с минимумом триггеров, а ограничения целостности вводятся не для обеспечения бизнес-логики, а для семантических оптимизаций.

REST-интерфейс выставляет наружу некоторую специальную информационную модель. Она достаточно нетривиальным образом ложится на модель данных.
Обычно в разговорах об архитектуре под CRUD понимают достаточно узкую штуку: это набор методов по манипуляции именно данными в таблицах.
То есть Update здесь — это просто Update, сохраняем атрибуты одной Entity. В Rest update — это PUT или PATCH; за ними мы ожидаем увидеть какую-то бизнес-логику.
Z>Откуда взялся мобильный клиент в теме про веб-фреймворки? Я говорил, что мне не нравится в веб-клиенте бизнеса, который, похоже, делался по принципу — засунем все в одно SPA.
Эмм, из обсуждения того, как устроены удобные для пользователя приложения.
Ещё раз поясню: мобильные приложения как раз демонстрируют современные достижения юзабилити.
Во-первых, потому что там нет адского легаси в стиле "отцы терпели — и ты потерпишь", а во-вторых, потому что мобильник сам по себе очень неудобен. И "традиционные" подходы на нём сосут. Достаточно попробовать открыть этот сайт на айфоне, чтобы получить наглядный пример.

То есть когда мы пишем мобильное приложение, то мы вынужденно думаем не о том, как "выставить в гуе" список заказов, список адресов, список кредитных карточек, и что там ещё у нас может быть списком, а о том, какие действия выполняет пользователь. И пляшем от них. В хорошем десктопном приложении надо делать так же. Но примеров таких приложений — гораздо меньше, чем мобильных.

REST, который выставляется между клиентом и сервером, может быть устроен существенно по-другому, чем GUI. И, естественно, существенно по-другому, чем внутреннее устройство таблиц БД.

Вот теперь на первый план выезжают фреймворки, которые помогают мне строить серверную часть вот таких вот приложений.
Не нравится мобильный клиент альфа-банка — ок, давайте посмотрим на какой-нибудь booking.com или momondo. Там главное "окно" — это выхлоп "поискового запроса". Нет никакой таблицы в БД, которая бы соответстовала view "подходящие варианты размещения". Там есть несколько таблиц, и нетривиальная логика по извлечению из них данных.

Z>Нет, я пытаюсь понять, почему "нормальные" интерфейсы не дают мне делать то, что мне нужно.
Вы просто взяли пример "плохого" интерфейса Я же не говорю, что он хороший — он плохой.
Но в том, что он плохой, виноват точно не тот фреймворк, который они взяли.

S>>Эмм, вы вообще master-detail видели? Ну, чтобы убедиться, что мы об одном и том же говорим?

Z>Я устал уже от отсылок к delphi, mobile, тонкостей толкования REST. Давай вернемся к теме и разберемся, чем конкретно хороша и плоха динамика в веб-разработке.
Отлично, давайте.
Z>Не надо мне в каждом посте "тонко" намекать, что твое толкование REST, нормального интерфейса или master-detail чем-то лучше моего. Если что-то считаешь лучшим решением, приведи его, объясни его плюсы, будь готов ответить на вопросы, а все эти намеки свысока "вы вообще master-detail видели" задолбали.
Прошу прощения, если мой тон вас обижает. Я всего лишь пытаюсь убедиться в соответствии терминологии, чтобы обсуждение было конструктивным.

Z>Понятно. Очень спорно, но не по теме. По теме это укладывается в REST и сценарий PATCH заказа. И вполне нормально вписывается в идеологию RoR.
Отлично. Вот мне хочется понять — каким образом идеология RoR помогает лучше, чем идеология C#/Linq.

Z>Возможно тебе хотели показать, насколько проще делаются банальные сценарии, потому, что показать что-то сложное за пять минут нельзя. А ты составил поверхностное суждение и теперь его отстаиваешь.
Не, я не отстаиваю. Я хочу разобраться в том, где я заблуждаюсь.

Z>Например, разве, делфи оказалась плоха, потому, что можно было бросить грид на форму? Между прочим это был прекрасный инструмент, который был вытеснен C# и .net, как языком так и платформой. Я сам в свое время перешел с радостью, надоело вручную управлять памятью и писать на паскале. Сам редактор форм там был ничуть хуже winforms, а во чем-то даже лучше.
Я тоже в своё время очень много написал на Delphi. Просто

Z>Точно так же я и на RoR ушел. Надоело вручную управлять парком велосипедов. Возможно есть приложения и бизнесы, в которых содержание этого парка оправдано, но мне не нравится аргументация в стиле: "отстутствие необходимости писать велосипед на каждый чих провоцирует нас не писать их совсем, это расслабляет и делает наши приложения неудобными для пользователей". Нужен велосипед — пишем. Преимущество RoR в том, что многое можно брать в готовом виде и кастомизировать ровно то, что нужно.

S>> Ничего странного в REST с "искусственными ключами" нету. И наличие привязки к ER не означает эквивалентность ER. Эта привязка может быть выполнена большим количеством разнообразных способов.

Z>Так в чем тогда проблема?
В том, что большая часть кода приложения — это преобразования данных из одной структуры в другую. В динамике это сводится к перекладыванию из одной хешмапы в другую. В статике — это преобразования типов.
И теоретически как раз статический контроль типов позволяет нам оперативно отслеживать некорректности этих преобразований. Я пока не могу понять, чем же динамика лучше.
Всё, что я услышал в качестве критики статики — "необходимость создавать и поддерживать бесчисленные DTO". Ну, так это справедливо только в том случае, если DTO нужно декларировать заранее и явно.
Современная статика копает в сторону автоматического вывода типов DTO вместо явного их описания.
То есть там, где в динамике мы в результате Select FirstName, LastName, DateDiff(Now(), BirthDate, Year) as Age получаем просто рекордсет, из которого надо доставать данные по именам, в статике мы получаем экземпляр анонимного типа со вполне определёнными типами FirstName, LastName, и Age. Что потенциально позволяет нам сразу же отлавливать несоответствия использования.
Z>Пусть будет PUT, мы опять ушли от темы. Где идемпотентно — PUT, где нет — POST. Если простое изменение данных, в сущность, если это операция — то в операцию. Как это относится к рельсам или .net?
Ок, вернёмся к теме. Каким образом нам рельсы помогают проверить корректность данных, приехавших в PUT?

Z>Насколько я понимаю, в этом плане все равно придется что-то изобретать для идемпотентности, хоть POST это будет, хоть PUT, задача программиста сделать идемпотентный обработчик не решается выбором глагола.
Выбор глагола подталкивает к решению. Когда мы реализуем PUT, то у нас уже есть resource id; и нам нетрудно реализовать if (newObject.Equals(existingObject)) return 200 Ok, чтобы пропустить весь блок бизнес-логики, связанный с изменением состояния (типа отправки письма "заказ принят" и прочих штук). Когда мы реализуем Post, то надо прямо отдельно думать о том, "а что если это не новая операция, а повторная отправка старой, которая потерялась".

S>>Ну, мне важнее всего код клиента. Потому что сервер — он один, а клиентов — много. С клиента реализовать корректную смену статуса через patch проще, чем через POST и прочее. Мне не надо прикапывать RequestID и прочее — вполне себе тупой клиент способен поддержать смену статуса, не приводя к ошибкам.

Z>Чем проще-то? Не могу понять. Ну кроме того, что не надо дополнительно документировать идемпотентность.
А что, одного этого мало? Даже тупой веб-клиент, который отправляет PUT, получит корректный результат при повторном нажатии на кнопку.

Z>Все остальное — тонкости понимания REST, предпочтения в UI, что там было в Delphi, идут параллельно теме и тоже совсем не конструктивно. Ты занял позицию гуру — кругом говно, читайте книги, там все рассказано. Я не просил совета, какие книги мне читать.
Можно и закруглиться. Я ожидал совета, какие книги мне почитать. Ну, или примеров про то, как RoR помогает. Вы приводите косвенные признаки — ваше приложение на рельсах проще, чем оно было бы на .Net.
Было бы интересно посмотреть на фрагмент RoR кода, который плохо перепишется на C#. Потому что без этого всё упирается в opinion и вкусовщину.