Metodyka komunikacji z bazą MSSQL - C#, jakie rozwiązanie preferujecie?

Witam, z góry przepraszam jeżeli duplikuje temat.
Chciałbym zasięgnąć Waszych opinii i doświadczeń w komunikacji aplikacji .NET z bazą danych MSSQL.
Która z opcji wydaje się bardziej rozsądna:

1. Aplikacja C# wywołuje procedury składowane na SQL w celu dodawania, usuwania , modyfikowania rekordów. Po stronie .NET jest tworzone SQLCommand typu Storedprocedure. Do sql command dodajemy parametry pochodzące z obiektu "Parameters.Add" i wykonujemy commad. Logikę biznesową staramy się przenieść w jak największym stopniu do SQL. SPrawdzanie na poziomie procedur składowanych, triggerów. Wyświetlanie wyników za pomocą funkcji SQL
2. Aplikacja bezpośrednio pisze po tabelach bez użycia procedur

Czy może inne podejście?

Jak zawsze wszystko zależy od aplikacji, ale jeśli w grę nie wchodzi ORM, znasz dobrze SQL i to ty jesteś za niego odpowiedzialny to zawsze 1.

Pierwsze podejście jest lepsze od drugiego, ale dla przeciętnej aplikacji pierwsze też jest złe. Jeśli jest to typowy CRUD, to lepiej użyć ORM. Jest szybciej, łatwiej i wygodniej się reaguje na zmiany w strukturze bazy.

Przede wszystkim możesz pomyśleć o linq'u. Jego wykorzystanie bardzo ułatwia pisanie programów obsługujących bazy danych. Ze względu na wydajność lepiej jak najwięcej operacji wykonywać bezpośrednio na MSSQL przy użyciu widoków, triggerów i procedur przechowywanych. Niestety przy pokrętnej logice programu czasami ujęcie jakiegoś zadania w procedurze przechowywanej jest niemożliwe albo procedura staje się tak rozbudowana i zagmatwana, że sam autor traci w niej rozeznanie. Wg mnie jak najwięcej danych należy przetwarzać bezpośrednio w MSSQL, ale nic złego nie ma taż w tym, że część informacji przetwarzana jest bezpośrednio w programie (czasami można zastosować schemat mieszany np. procedura przechowywana zwraca wstępny zakres danych np. z milona rekordów 10 tys., a w programie następuje ich dalsza obróbka i otrzymujemy 100 rekordów)

Dziękuję bardzo za wskazówki.
Jestem właśnie na etapie tworzenia aplikacji do zarządzania nieruchomościami. Niestety po raz kolejny okazało się, że zmieniła się specyfikacja wymagań - której tak naprawdę nie ma :-(.
Wczorajszy dzień poświęciłem np na konstruowanie tabel MSSQL w oparciu o definicję klas. DO jednej tabel skonstruowałem procedurę dodającą rekordy w MSSQL i metodę w klasie odpowiedzialną za spreparowanie zapytania wraz z parametrami.
Dziś się okazała , że cała praca poszła na marne :-( - Zmieniła się definicja klasy a tym samym powinna się zmienić definicja tabeli , procedury...

Zastanawiam się, czy aby na pewno mam poprawną kolejność działań. Chcąc pokazać dla klienta, że cokolwiek jest zapisywane i odczytywane do bazy śpieszę ze stworzeniem stosownych tabel procedur..
Jednak Klient wprowadza zmiany i... ech..
Jak to wygląda u Was? Czy może macie inną metodę biorąc pod uwagę mozliwe zmiany...

Szukam też kogoś do pomocy w postaci płatnej pracy zdalnej lub posłużeniem wskazówkami przy pewnych pytaniach (również za opłatą).. może ktoś jest zainteresowany?
POzdrawiam

W takiej sytuacji lepiej nie bawić się w metodę class first lecz wybrać base first. Przede wszystkim skup się na bazie i opracuj jest strukturę. Na tym etapie twórz formularze "zgrubne" nie bawiąc się w szczegóły tylko tyle aby można było sprawdzić czy to jest to czego oczekuje klient. Jak osiągniesz już stabilność w strukturze bazy wtedy będziesz mógł zając się formularzami. Jeżeli jest to projekt komercyjny to niestety trzeba usiąść z klientem i omówić każde zadanie, którą ma robić program. Ogólnie w tego typu projektach problemem nie są sprawy techniczne (zakładając, że ktoś już kilka programów tego typu napisał), ale właśnie zrozumienie co program ma robić i o czym jeszcze klient zapomniał powiedzieć. Dobrą metodą jest rozpoczęcie rozmowy od wydruków jakie mają wyjść z programu. Wtedy będziesz widział jakie dane MUSZĄ zostać wprowadzone do programu (pod warunkiem, że nie chodzi o portal ogłoszeniowy w intenecie, ale obsługę nieruchomości tj. wystawianie rachunków, przeglądy okresowe, liczniki itp.).

dubo napisał(a):

Zastanawiam się, czy aby na pewno mam poprawną kolejność działań. Chcąc pokazać dla klienta, że cokolwiek jest zapisywane i odczytywane do bazy śpieszę ze stworzeniem stosownych tabel procedur..

A po co Ci w ogóle te procedury? Samodzielne pisanie kodu SQL to strata czasu. A pisanie jakichś klas i metod konstruujących te zapytania jeszcze większa.

cw napisał(a):

W takiej sytuacji lepiej nie bawić się w metodę class first lecz wybrać base first.

No właśnie w takiej sytuacji nie ma co zaczynać od bazy.
Tu trzeba zrobić prototyp - czyli ekrany wypełnione jakimiś danymi. Do tego potrzebne są klasy reprezentujące obiekty biznesowe, i powiązane z nimi ekrany. Jakieś testowe dane można sobie wpisać na sztywno w aplikację, i niech przy uruchamianiu ekrany się nimi wypełniają. Dopiero, gdy klient zaakceptuje prototyp, tworzy się schemat bazy na podstawie klas i pisze realną funkcjonalność.

Od bazy można zaczynać tylko i wyłącznie wtedy, gdy jest się pewnym, co chce się zrobić.

"Tu trzeba zrobić prototyp - czyli ekrany wypełnione jakimiś danymi. Do tego potrzebne są klasy reprezentujące obiekty biznesowe, i powiązane z nimi ekrany" owszem gdyby to był bardzo duży projekt i inni ludzie zajmowaliby się warstwo wizualną, a inni bazą danych. Ponieważ tu jedna osoba pisze cały program to łatwiej będzie pracować bezpośrednio na bazie danych niż budować prototypy i generować próbne dane

cw napisał(a):

owszem gdyby to był bardzo duży projekt i inni ludzie zajmowaliby się warstwo wizualną, a inni bazą danych.

o.O A jakie to ma znaczenie, ilu jest ludzi w projekcie? Zaczynanie od prototypu ma sens w każdej niejasnej sytuacji.

cw napisał(a):

Ponieważ tu jedna osoba pisze cały program to łatwiej będzie pracować bezpośrednio na bazie danych niż budować prototypy i generować próbne dane

Ciągłe przerabianie bazy, powiązanej z nią częścią aplikacji i GUI jest jakimś ułatwieniem? Zdecydowanie łatwiej jest wtedy, gdy masz mniej zmian do wykonania, czyli wtedy, gdy masz tylko klasy i GUI.

Tak też zrobiłem.
Najpierw powstał prototyp, z podstawowymi formatkami i sztucznymi danymi. Kiedy się już wydawało , że omówiliśmy dokładnie np formularz właściciela lokalu na bazie jego pól stworzyłem klasę właściciel. Na podstawie klasy stworzyłem tabelę w MSSQL i dodatkowo procedurę do niej zapisującą. Procedurę po to , abym mógł na poziomie MSSQL reagować na błędy i już na jej etapie sprawdzać poprawność danych zanim się je dołoży do tabeli.
Oczywiście można by stwierdzić, że poprawność danych łatwiej sprawdzić na poziomie aplikacji. Ale co będzie w przypadku jezeli raptownie klient zażyczy sobie mieć te dane i funkcjonalności na www (inna technologia niż .NET),tablecie.

Po zaprogramowaniu klasy, tabeli -właściciel dnia kolejnego okazało się, że właścicielem tak naprawdę może być kilka osób , i te kilka osób formalnie jest nazwane właśicielem. W związku z tym zmienia się koncepcja.
Powstaje klasa osoba i oddzielna klasa właściciel zawierająca jedną lub kilka osób.. Każda z osób ma oddzielne adresy, telefony, lecz właściciel ma dodatkowe dane w postaci np jednego adresu do korespondencji.

Czyli zmiany, zmiany...
Może faktycznie zostawię bazę danych na sam koniec, wcześniej skupię sie na klasach, formularzach.
Najgorsze jest jednak to, że klient chce zobaczyć jak działa mechanizm wyszukiwania.. i tu , żeby zasymulować specyficzne wyszukiwanie prototyp staje się dość skomplikowany..

Tak ogólnie to szukam kogoś do pomocy, najchętniej osoby posiadającej działalność gospodarczą, która by mogła wspólnie ze mną popracować 1-2h co jakiś czas.
Praca zdalna za pomocą TeamViewer na który posiadam licencje. Rozliczamy godziny pracy fakturą.
Pozdrawiam

dubo napisał(a):

Na podstawie klasy stworzyłem tabelę w MSSQL i dodatkowo procedurę do niej zapisującą.

I straciłeś czas.
Serio, poświeć klika dni na naukę jakiegoś ORM wspierającego podejście code-first, np. Entity Framework albo Fluent NHibernate. Potem już nigdy nie będziesz tracił czasu na robienie tego, co od dawna można zrobić automatycznie.

Ale co będzie w przypadku jezeli raptownie klient zażyczy sobie mieć te dane i funkcjonalności na www (inna technologia niż .NET),tablecie.

I myślisz, że na całym świecie jedynym stosowanym rozwiązaniem tego problemu jest wpychanie walidacji do bazy danych?

Jeśli przewidujesz, że tak może się stać, to powinieneś od razu tworzyć aplikację wielowarstwową, i logikę biznesową, walidację danych oraz operacje bazodanowe umieścić w jakichś serwisach webowych. Wtedy możesz sobie do tego podpiąć dowolnego klienta - aplikację Javową na Androida, stronę WWW w PHP, albo program desktopowy w Delphi...

A jeśli nie chcesz serwisów webowych, to wystarczy rozsądna architektura aplikacji (np. oparta o wzorzec MVP), dzięki czemu zmiana typu aplikacji (desktop, konsola, www...) jest banalna, bo wystarczy właściwe dopisać nowe GUI, cała reszta zostaje bez zmian.

Po zaprogramowaniu klasy, tabeli -właściciel dnia kolejnego okazało się, że właścicielem tak naprawdę może być kilka osób , i te kilka osób formalnie jest nazwane właśicielem. W związku z tym zmienia się koncepcja.

A masz w ogóle gdzieś spisane wymagania funkcjonalne tej aplikacji? Bo jeśli nie usiedliście z klientem, i nie porozmawialiście dokładnie o tym, czego on chce, i nie spisaliście tego, to takich kwiatków będziesz miał masę.

Powstaje klasa osoba i oddzielna klasa właściciel zawierająca jedną lub kilka osób.. Każda z osób ma oddzielne adresy, telefony, lecz właściciel ma dodatkowe dane w postaci np jednego adresu do korespondencji.

A to nie wystarczy po prostu powiązać lokal z kolekcją właścicieli?

Najgorsze jest jednak to, że klient chce zobaczyć jak działa mechanizm wyszukiwania.. i tu , żeby zasymulować specyficzne wyszukiwanie prototyp staje się dość skomplikowany..

No więc trzeba napisać klasę wyszukującą dane w pewnej kolekcji obiektów. W ramach prototypu tą kolekcją będzie jakaś sztywna lista danych, a później bez problemu podmienisz ją na kolekcję wczytaną z bazy. Żaden problem.