Проработав 14 лет на Дельфи и Firebird я решил изучить C#, для чего поставил VS2015. После пары дней ковыряния в нем возникло много вопросов.

Кто-нибудь вообще приложения БД с Firebird на Visual Studio С# пишет? Существуют ли какие-то стандартные подходы?

Я разобрался как через дизайнер создать подключение и DataSet, полюбовался на 2000 строк кода, сгенерированного от добавления двух select запросов, и задумался - а в чем смысл этого?

Создавать копию всей БД? Наверное, для чего то круто, но тут нафиг не надо качать на всех клиентов кучу ненужных данных.

Смотреть на DataSet как на аналог TDataModule?

Считать каждый DataSet представление некоей сущности - например, документа определенного типа (несколько запросов из разных таблиц + методы обновления)? Однако, этому мешает сложность задания для него простейших правил - всяких аналогов AfterInsert, BeforePost и т. д. - из дизайнера самого DataSet они не создаются, возможно надо вручную писать в коде этого DataSet.Designer.cs, если его вообще можно редактировать - но 2000 строк сгенерированного кода отбивают желание туда лезть.

Забить вообще на все эти дизайнерские штучки и писать все руками, включая тексты sql-запросов прямо в коде? Так, конечно, можно. Но правильно ли?

В принципе, несложно, наверное, сделать свой аналог FIBDataSet со свойствами SelectSQL, InsertSQL и т. п., внутри которого обращаться к C# адаптерам и датасетам. Но если это правильно, почему этого до сих пор никто не сделал?

Пришла мысль - использовать этот сгененрированный в дезайн-тайм DataSet как хранилище текстов sql-запросов и ничего больше. В принципе, есть плюс, когда один запрос используется в разных формах. Но возникает вопрос - а как тогда с параметрическими запросами быть, коих, как правило, большинство?

Да, я привык, что логика в БД на триггерах и процедурах, а клиент относительно тонкий.

IMHO очевидно, что DataSet слизан с TClientDataSet и Мidas.

Как сочетать объекты данных с реляционной БД я не понимаю. IMHO скорость будет страдать по любому. Мы засовываем данные в объект на клиенте - это, конечно, здорово, только половина логики остается на сервере и что с этим делать? Или использовать реляционную БД просто как хранилище, вроде кучи DBF файлов? Нафиг надо.

слой работающий непосредственно с БД расположен в web-сервисе

То есть трехзвенка? Для трехзвенки, понятно, по-другому. А насколько сложна логика работы?

Есть аналог TDBGrid?

Есть. Только на сколько я понял чтобы туда колонки в дизайн-тайм добавлять обязательно надо создать в этом странном дизайнере типизированный датасет. То есть к каждой форме надо еще отдельно этот датасет создавать - в отдельном файле, который определяет сам тип наборов данных. А на форму кладется датасет, включающий дататейблы этих типов. Вот тогда можно в грид в дизайн тайм колонки добавлять. А так - нет. Только колонки, ни с чем не связанные. Непонятно, почему в дизайнере нельзя было позволить добавлять колонки нужных типов.