Dapper - trzymanie zapytań w kodzie vs tworzenie widoków/procedur w bazie

Witam.
Gdzie trzymacie zapytania? Wydaje mi się, że kodowanie tego w całej aplikacji jest mało wygodne. Każda zmiana wymaga kompilacji całego programu lub konkretnej biblioteki. W związku z tym, że mój projekt jest "dziwny" i nie podlega pod jakiekolwiek standardy, pytanie te może być retoryczne, czyli żadne rozwiązanie nie będzie idealne, albo, jak to zwykle bywa w tego typu problemach, odpowiedź będzie brzmiała - "to zależy".

Pytam o to, ponieważ robi się straszny bałagan. Korzystając z Dappera muszę pobierać każdą kolumnę z osobna, aby ją odpowiednio nazwać, ponieważ domyślne nazwy kolumn są paskudne. Zapytania robią się długie, w Visualu (jako string) jest to mało czytelne, składnia się nie koloruje, nie robi odpowiednich wcięć.

PRZYKŁAD

(select 
Knt_kntId [Id], 
Knt_Kod [Code],
Knt_Nazwa1 + ' ' + Knt_Nazwa2 + ' ' + Knt_Nazwa3 [Name], 
Knt_Nip [VatNumber],
Knt_Regon [Regon],
Knt_Pesel [Pesel],
Knt_KodPocztowy [ZipCode],
Knt_Miasto [City],
Knt_Ulica [Street],
Knt_NrDomu [BuildingNumber],
Knt_NrLokalu [ApartmentNumber],
Knt_Telefon1 [Phone1], 
Knt_Telefon2 [Phone2],
Knt_TelefonSms [Phone3],
Knt_Email [Email],
Knt_Grupa [Group],
Knt_KrajISO [CountryCode],
case when Knt_PodatekVat = 1 then 'Podatnik VAT' else '' end [VatStatus],
case when Knt_Rodzaj_Dostawca = 1 then 'Dostawca' else '' end [Provider],
case when Knt_Rodzaj_Konkurencja = 1 then 'Konkurencja' else '' end [Competition],
case when Knt_Rodzaj_Odbiorca = 1 then 'Odbiorca' else '' end [Recipient],
case when Knt_Rodzaj_Partner = 1 then 'Partner' else '' end [Partner],
case when Knt_Rodzaj_Potencjalny = 1 then 'Potencjalny' else '' end [Potential],
(select FPl_Nazwa from CDN.FormyPlatnosci where FPl_FPlId = Knt_FplID) [PaymentName],
Knt_FplID [PaymentId],
case when Knt_Waluta = '' then 'PLN' else Knt_Waluta end [Currency],
Knt_Nieaktywny [isActive],
Knt_Termin [PaymentDays],
Knt_Finalny [CountedFrom],
Knt_Ceny [Price],
Knt_LimitKredytu [LoanLimit],
Knt_LimitPrzeterKredytWartosc [LoanOverdueLimit],
Knt_LimitKredytuWykorzystany [LoanLimitUsed],
(select sum((BZd_Kwota - BZd_KwotaRoz) * BZd_Kierunek) from CDN.BnkZdarzenia
where BZd_Rozliczono = 1 and BZd_PodmiotID = Knt_KntId and convert(date, Bzd_Termin) <= convert(date, getdate()) and BZd_Stan = 1) [AfterPaymentDate]
from CDN.Kontrahenci) as Customers where (1=1) 

PS.
Pomysł z OData niestety odpada. Struktura bazy danych Optimy jest tak paskudna, że nie mogę skorzystać z EF, mimo iż ma opcję database first korzystając z db-scaffold. A Dapper + OData to jest bardzo słabe połączenie. Postanowiłem, że wrócę do Dappera, ale filtrowanie danych zrobię "po swojemu" korzystając z rozwiązania jakie ma OData (select, filter, orderBy itp.), a to się wiąże z trzymaniem gdzieś zapytań.

Masz uprawnienia do tej bazy, które pozwalają na dodawanie i edycję jej składowych?
Zazwyczaj jak już się trzyma jakieś sqle to w dedykowanych projektach bazodanowych, które można wygodnie sobie tam przechowywać, edytować i generować z nich skrypty migracyjne.
W takim przypadku wygodniejszym rozwiązaniem byłoby pewnie użycie procedur składowanych a wtedy z poziomu dappera przekażesz tylko parametry i wyciągniesz sobie wynik zapytania.

No właśnie uprawnienia mam pełne do każdej bazy. Problem zaczyna się gdy jest kilka firm. Optima pozwala na zmianę firmy (bazy firmowej), a to wiąże się z duplikowaniem tego samego w każdej bazie. Jedyne co jest stałe to baza konfiguracyjna (przeważnie jest jedna) i to właśnie tutaj mógłbym dopisywać swoje rzeczy. Tworzenie własnej bazy chyba sensu nie ma. Trzeba też wziąć pod uwagę to, że zapytania nie są parametryzowane jak Dapper nakazuje. Jestem zmuszony budować zapytania na bazie własnego modelu, na wzór OData. Jeśli już miałbym trzymać w bazie zapytania to w postaci takiej jak w przykładzie wyżej. Reszta jest generowana.