SQL DSL dla .NET podobny do jOOQ

Witam,
Czy możecie polecić bibliotekę dla .NET, pozwalającą na obiektowe, ale bezpieczne względem typów budowanie zapytań SQL? Nie chcę używać ORM. W świecie Javy idealnym narzędziem do tego wydaje się być jOOQ (http://www.jooq.org/). Fajnie aby opcjonalnie było dostępne wsparcie komercyjne. Najbardziej mile widziane są jednak produkty open-source.

Zależy mi na wsparciu dla baz:

• MS SQL Server
• PostgreSQL

Idealnie, aby biblioteka była open-source (przynajmniej dla otwartch baz jak jOOQ). Bardzo mile widziane opisanie doświadczeń, dlaczego polecacie. Kiedy uważacie, że taki DSL jest lepszym wyborem niż Entity Framework itp.

Pozdrawiam,

Nie znam JOOQ, przejrzałem tylko tę stronkę. Może po prostu użyj wbudowanego w .Net LINQ wraz z ADO?
Tutaj przykłady użycia LINQ to SQL
https://msdn.microsoft.com/pl-pl/library/bb882643%28v=vs.110%29.aspx

W google znajdziesz więcej oczywiście przykładów.

A co do polecania:
Ja wolę używać ORM, dla wygody. Głównie NHibernete'a. Gdy potrzebowałem lekkiego ORM to używałem Dappera. Dobrze się sprawdzał.
Nie wiem czego potrzebujesz dokładnie, na 1 rzut oka najprościej to LINQ użyć. Nie wiem czemu nie chcesz używać ORM, pewnie masz swoje powody.

Zdaje się, że LINQ to SQL to abstrakcja, która generuje gdzieś pod spodem natywnego SQLa. Tutaj wymaganie jest inne. Chcę przygotować prototyp aplikacji do raportowania,czyli budowania skomplikowanych zapytań w prawdziwym SQLu (ale bez klejenia stringów tylko obiektowo jak jOOQ), czasem procedur, aby nie przerzucać aplikacji między bazą, a aplikacją i znowu wracać do bazy. Tu chodzi o proof-of-concept.

Korzystałem z Hibernate, gdy robiłem raportowanie znacznie łatwiej było mi pisać natywne zapytania niż stosować abstrakcje. W przypadku dynamicznych zapytań stosowałem jOOQ, aby ułatwić sobie życie składniowo.

ORMa używałbym gdybym chciał wygenerować bazę na podstawie encji nie widząc jakiego silnika będę używał, to trochę inny usecase. Wiem, że się da. Zawsze można pokombinować z wystawieniem skomplikowanych zapytań jako widoków (zrobić encje), ale tak się tylko zastanawiam czy jest jakiś fajny DSL dla .NET. jOOQ będzie portowany, ale nie wiadomo kiedy wydadzą.

NHibernate, ani żaden inny ORM to nie są narzędzia do raportowania, do tego służą inne technologie, zazwyczaj z "reporting" w nazwie.

Ogólnie tendencja jest taka, żeby abstrahować SQL na rzecz bardziej intuicyjnych języków. Rozumiem, że celem tego jOOQ jest ułatwienie bazodanowcom na pisanie w normalnych językach? Nie słyszałem nigdy o podobnym narzędziu w .NET.

Chodzi o dynamiczne zapytania w natywnym SQL (np. aby dynamicznie dodawać parametry do WHERE w SQL w zależności od potrzeb). Do projektów, w których się głównie czyta, a baza najczęściej już stoi od jakiegoś czasu. Jak WHERE się nie zmiania to nie ma tematu. Ja wiem, że da się to robić za pomocą klejenia string, ale na pewno można lepiej.

Rolą .NET byłoby tak naprawdę wystawianie usług REST: (GUI w JS).

ORM bym był skłonny zastosować przy zapisie, aby mieć wygodną transakcję (ale mi chodzi głównie o odczyt).

ORM pozwala dynamicznie generować zapytania, które są tłumaczone na SQL.
Jakby ciągle nie rozumiem na czym faktycznie polega zadanie.

Pracując z Hibernate nie zawsze byłem zadowolony z jakości zapytań, wygenerowanych przez ORM. Do prostych query ORM był spoko. Dla trudniejszych (czasem dynamicznych przypadków) wolałem sam pisać SQL niż pozwalać ORMowi decydować jak zrobić zapytanie. Może za słabo rozumiem ORMy i powinienem się poduczyć. jOOQ pozwalał mi łatwo pisać zapytanie natywne (a nie tłumaczyć strukturę ORM na natywne) korzystając z notacji obiektowej: kompromis między jednym, a drugim.

Ale to tylko ułatwienie / cukierek składniowy. Dzięki za zainteresowanie, jak coś się pojawi (biblioteki DSL do natywnego SQL dla .NET) to chętnie się dowiem.

Wygląd zapytania przy komunikacji z bazą danych nie powinien mieć najmniejszego znaczenia, jeśli tylko koszt zapytania jest w okolicach optimum. To koszt zapytania się optymalizuje, a nie wygląd generowanego sql. Co do "sklejania stringów", to zobacz profilerem, że np. EF używa parametrów, a jeśli to dla Ciebie za mało, to użyj precompiled query.
BTW kiedyś, kiedy dopiero rodziło się LINQ, Microsoft pracował nad innym, alternatywnym rozwiązaniem do tworzenia zapytań, wyglądało to prawie jak sql i wydaje mi się, że Tobie mogłoby to podpasować, tylko nie dość że nie pamiętam nazwy, to jeszcze wydaje mi się, że jakiś czas temu projekt został porzucony. Poszukaj, może znajdziesz.