Witam, poszukuję dobrze napisanej klasy do łączenia i zarządzania bazą danych (insert, select, update itp). Znalazłem co prawda kilka fragmentów takich klas, jednak pomimo mojej słabej znajomości języka C# (jeszcze :) ) wiem, że nie jest to do końca poprawne.
Będę bardzo wdzięczny za pomoc.
0
0
Solidna klasa? Na sam początek polecam Ci framework Simple Data. Podajesz tylko connectionString w App.conf i dalej już leci. Jest możliwość zapisywania całych obiektów i kod z tycm fremworkiem wygląda naprawdę całkiem dobrze. Nie rozrasta się jak w przypadku DataSet ów i DataReaderów.
0
Wygląda bardzo ciekawie, szczególnie jeśli chodzi o wykonywanie zapytań... jedna linijka i po kłopocie. Trochę na ten temat poczytałem, ale przydał by mi się jeszcze jakiś wzorcowy przykład. Co prawda na stronie projektu jest sporo ciekawych informacji, jednak dla kogoś kto dłużej programuje w C#. Dla mniej zaawansowanych jest to trochę trudniejsze:) no nic, będę walczył, a jak na razie dziękuję za cenną wskazówkę.
1
Świetnym rozwiązaniem jest Entity Framework. Ogólnie są trzy sposoby obsługi baz danych w C#: connected layer, disconnected layer i właśnie Entity Framework. Dwa pierwsze sposoby przeze mnie wymienione wymagają (przynajmniej podstawowej) znajomości SQL (albo jego odmiany T-SQL). Jeżeli jednak nie jesteś w SQL obeznany to przy Entity Framework dodanie obiektu do bazy danych wygląda np. tak:
BazaDanychEntities bazaDanych = new BazaDanychEntities();
//(i teraz zakładając, że w bazie jest tabela z kolumnami Id-klucz, Imie, Nazwisko, Wiek) obiekt dodajesz tak:
bazaDanych.Ludzie.add(new Person() { Imie = "Stefan", Nazwisko = "Kowalski", Wiek = 21 });
Odpowiedni kod SQL jest generowany "za kulisami". Podsumowując, możesz sam sobie stworzyć bardzo szybko klasę, która będzie miała właśnie kilka takich funkcji do obsługi bazy.
0
Moim zdaniem brak znajomości SQL-a nie jest usprawiedliwieniem na wybór odpowiedniej metody na pracę z bazą danych bo raz doda obiekt, drugi raz i za trzecim razem będzie chciał uzyskać o wiele większą i złożoną treść z bazy danych i będzie musiał napisać procedurę ( co wymaga znajomości SQL ). Btw. Simple Data też automatycznie generuje kod ( co jest logiczne ), umożliwia takie samo dodawanie obiektu i błyskawiczne wywołanie procedur składowanych. Jak patrzę właśnie na SD to zastanawiam się kiedy wypada użyć ORM-a ( nHibernate np. ort! fakt automatyczne mapowania klas na tabele jest mocny.. ). Do małych i średnich projektów moim zdaniem SD bardzo się przydaję.
2
qwertty43 napisał(a):
Ogólnie są trzy sposoby obsługi baz danych w C#: connected layer, disconnected layer i właśnie Entity Framework.
Taa....
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET
A i to nie wszystko, nie widać tam np. Telerik Open Access ORM.
Dwa pierwsze sposoby przeze mnie wymienione wymagają (przynajmniej podstawowej) znajomości SQL (albo jego odmiany T-SQL).
W przypadku DataSetów normalnie można zapytania wyklikać, więc SQL niby znać nie trzeba.
Masz jakieś doświadczenia z EF i MySQL? Działa to jakoś sensownie?
0
Ogólnie są trzy sposoby obsługi baz danych w C#: connected layer, disconnected layer i właśnie Entity Framework.
Taa....
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET
A i to nie wszystko, nie widać tam np. Telerik Open Access ORM.
Somekind, ja mówię o standardowych sposobach, w które jest wyposażony .Net, i są trzy, ni mniej, ni więcej (nie chcę się tutaj wykłócać , po prostu tak to zapamiętałem z książki pro c# 5.0 and the .net 4.5 framework - autor Andrew Troelsen, nawiasem mówiąc, według mnie jedna z najlepszych pozycji o C#, może jeszcze oprócz C# via CLR) . To co podałeś to dodatkowe connectory.
Ja obecnie pracuję z EF i mysql. Działa to świetnie. Pracuje się przyjemnie i szybko. Dodatkowym plusem jest to, że przy mojej strasznie słabej znajomości tematyki baz danych i języka SQL mogę bez jakiegoś nadzwyczajnego wysiłku pracować nad aplikacją.
1
qwertty43 napisał(a):
Somekind, ja mówię o standardowych sposobach, w które jest wyposażony .Net, i są trzy, ni mniej, ni więcej (nie chcę się tutaj wykłócać , po prostu tak to zapamiętałem z książki pro c# 5.0 and the .net 4.5 framework - autor Andrew Troelsen, nawiasem mówiąc, według mnie jedna z najlepszych pozycji o C#, może jeszcze oprócz C# via CLR) .
To też nieprawda, bo Linq to SQL jest w standardzie.
To co podałeś to dodatkowe connectory.
Z których można korzystać w C#.
0
To też nieprawda, bo Linq to SQL jest w standardzie.
To jest dopiero nieprawda. Linq nie ma nic wspólnego z łączeniem się z bazą danych, nie jest to w żaden sposób równorzędne tym trzem sposobom, które wymieniłem. Za jego pomocą można ją obsługiwać, ale nie łączyć. Co do dodatkowych connectorów to do mysql oczywiście trzeba dodać referencję do projektu : Mysql.Entity.dll i Mysql.data.dll
1
qwertty43 napisał(a):
To jest dopiero nieprawda. Linq nie ma nic wspólnego z łączeniem się z bazą danych, nie jest to w żaden sposób równorzędne tym trzem sposobom, które wymieniłem.
Nie, LINQ to SQL nie ma nic wspólnego z bazami danych, i nie może być stosowany zamiast EF czy DataSetów:
In LINQ to SQL, the data model of a relational database is mapped to an object model expressed in the programming language of the developer. When the application runs, LINQ to SQL translates into SQL the language-integrated queries in the object model and sends them to the database for execution. When the database returns the results, LINQ to SQL translates them back to objects that you can work with in your own programming language.
1
@qwertty43, na Twoim miejscu bym wyluzował z oskarżeniami o trolling. Ja tylko zwróciłem Ci uwagę, że podajesz (tzn. wg tego co napisałeś, to Troelsen podaje) nieprecyzyjne informacje. Linq to SQL jest technologią dostępu do baz danych, może być używany zamiast np. Entity Frameworka, i jest dostępny standardowo w Visual Studio od wersji 2008. Możesz sobie w projekcie zrobić: Add -> New Item -> i w zakładce Data wybrać "LINQ to SQL Classes". Masz tam dostępny designer, w którym możesz sobie przeciągnąć tabele z bazy, i który wygeneruje kod klas encji i klasy kontekstu, dokładnie tak, jak dzieje się to w EF.
Nie wiem czemu tak bardzo upierasz się przy swoim i próbujesz przeczyć rzeczywistości. ;]
0
Osobiście uważam, że jeśli chodzi o MySQL czy sam SQL, to jest on niezbędny przy pisaniu aplikacji bazodanowych. Przynajmniej podstawy i zasady konstruowania zapytań, ja sobie nie wyobrażam bez tego programowania. W chwili obecnej przesiadam się z PHP i 99% zagadnień związanych z programowaniem z C# (łącznie z frameworkami) jest dla mnie czarną magią. Składnia języka wydaje się być prosta i przyjemna, ale jeśli chodzi o jakieś konkretne przewodniki, takie typowo łopatologiczne to już gorzej. Pamiętam jak zaczynałem przygodę z ORM i frameworkami w PHP, było podobnie, jednak bardziej przejrzyście opisane. Bardzo dziękuję za powyższe informacje, cieszę się, że temat się tak rozwinął, bo przyznam, że początkowo obawiałem się, że zostanę "zakrzyczany" żebym sobie to wszystko odpuścił :) tak więc duży plus dla forum i użytkowników, pod tym względem pewne spore forum php nie dorasta Wam do pięt, ale dosyć tego słodzenia :)
Wracając do tematu, wiem, że ilu użytkowników tyle wersji i dorad, ale... po przeczytaniu kilku ostatnich postów proszę o doradę (przyda się pewnie nie tylko mnie) chciał bym napisać prosta aplikację okienkową, najlepiej, żeby każde okienko nie otwierało się osobno ale, żeby wszystko działało jak typowy word, czy inne podobne programu (klikam na pozycję menu i zmienia mi się zawartość okna zamiast wyświetlać nowe). Jaki więc framework na początek najlepiej wybrać. Baza danych nie będzie wybitnie rozbudowana max 4-5 relacji. Pozytywnym aspektem jest generowanie zapytań z "automatu" oszczędziło by mi to mój czas (którego i tam mam bardzo mało).
Z góry dziękuję za kolejne informacje :)
0
Kładziesz panel ( główny ) a na niego UserControl ( operujesz właściwościami Visible ). Do tego frameworków raczej nie ma? A jeżeli chodzi o pracę z bazami danych to w temacie przewinęły się:
- Simple Data
- nHibernate
- Entity Framework
0
Entity Framework + connector do MySQL'a (z oficjalnego strony MySQL'a lub z NuGeta). Wszystko elegancko hula. Nawet automatyczne migracje z EF5 działają. Sam teraz robie jeden projekt EF5 + MySQL (zamiast standardowego MSSQL), ponieważ klient ma ograniczony budżet.