Zapytanie z parametrami do MySQl

Prosty problem: przekazywanie parametrów do zapytania. Jeśli wpisze konkretną wartość pod @number to wszystko działa OK.
Istnieje dużo przykładów w sieci, ale żaden nie pasował do mojego..

String Query = "DELETE FROM samochod WHERE samochod_id = @numer";
                MySqlCommand cmd = new MySqlCommand(Query, Glowna.serwer.connection);
                MySqlParameter param = new MySqlParameter();
                param.ParameterName = "@numer";
                param.Value = indeksy.Count; // wartość integer
                cmd.Parameters.Add(param);
                cmd.ExecuteNonQuery(); 

Ma być:
param.ParameterName = "numer"

Dziekuje;)

A tak przy okazji to jeśli zamierzasz tworzyć większe systemy bazodanowe to zainteresuj się NHibernate. Tym samym uczynisz swoje życie prostszym.

--
Pozdrawiam
Marcin

Są prostsze rozwiązania niż NHibernate.

Ale czy skuteczniejsze i bardziej elastyczne? Chętnie poznam twoje propozycje.

Napisałem prostsze.
Taki Linq to SQL czy Entity Framework w przeciwieństwie do NHibernate posiadają designery, które automatycznie wygenerują klasy, nie trzeba pisać samodzielnie kodu i mappingów jak w NHibernate.
Co do skuteczności i elastyczności - nie wiem co masz na myśli.

szczerze, polecam pobawic sie tym designerem, pozmieniac sobie w nim nazwy klas i pol na != nazwom tabel i kolumn, a potem zrobic pare rename'ow na bazie i "update" na modelu entity :) ah, i koniecznie wpierw zbackupowac poprzedni edmx - gdyz jesli nie masz wprawy, to po 'update' Twoj edmx bedzie do wyrzucenia/zregenerowania i Twoje nowe kodowe nazwy ida won i trzeba od nowa wprowadzac..

..zas jezeli masz wprawe, to wiesz ze po update trzeba czasem recznie .edmx poprawic ---- i w tym momencie, ja wole NHibernate, bez recznego pisania/poprawiania xml, tylko z NH.Attributes na kazdej mojej klasie DAO. fakt - napisane recznie, od szablonu, ale - wole to niz edycje kilkutysiacliniowego .edmx ktorego designer znowu zaliczyl FAIL'a

Dla mnie to jasne, że po zmianie struktury bazy trzeba wygenerować na nowo model, lepiej w nim tez nie zmieniać wygenerowanych nazw ani też typów danych, no chyba, że lubi się dodatkową robotę. ;) Ale z tym chyba nie ma problemu - jeżeli mamy sensowne nazwy w bazie, to jesteśmy w domu.
Automatyczne wygenerowanie wszystkich mapowań trwa sekundę, napisanie tego w NHibernate znacznie dłużej. Moim zdaniem na tym polega prostota - oszczędzamy na czasie tworzenia, nie na wydajności czy elastyczności. :)

@somekind, mysle ze oszczedanie na czasie tworzenia moze sie odbic czkawka, Bo prawda zamiast 5 godzin masz 1, ale jak juz to zrobisz to pytanie co dziala szybicje i mysle ze to jest wazniejsze niz ile zabierze Ci tworzenie mappowan.

Plus mozesz zawsze uzyc generatora do stworzenie ORM'a nie musisz robic tego recznie.

Pozdrawiam

Co do odbijania czkawką - w aplikacji, która będzie miała góra 5 użytkowników łączących się z jedną bazą ok. 30 tabel, nie będzie problemów z wydajnością. A 5 sekund generowania zamiast 5 godzin pisania mapowań, to w tym przypadku mój zysk. :) Jeśli jednak zajdzie potrzeba użycia lepszego ORM, to jeśli projekt jest podzielony na warstwy nie będzie z tym problemu.
Do projektu na studia też bym nie użył NHibernate, bo szkoda czasu i energii na to.

Plus mozesz zawsze uzyc generatora do stworzenie ORM'a nie musisz robic tego recznie.

Znasz jakiś generator do NHibernate? Ja niby jakiegoś używałem, ale był tak słaby, że musiałem i tak napisać wszystko ręcznie.

Jesli chcesz poswieci troche czasu to zawsze jest MyGeneration, ale nie znalazlem templatow ktore by mi pasaowaly wiec musialem napisac swoje.

Jesli piszesz w ASP.NET MVC to istnieje S#ARP Architecture, ale nigdy nie uzywalem.

Pozdrawiam

Co do odbijania czkawką - w aplikacji, która będzie miała góra 5 użytkowników łączących się z jedną bazą ok. 30 tabel, nie będzie problemów z wydajnością. A 5 sekund generowania zamiast 5 godzin pisania mapowań, to w tym przypadku mój zysk.

Moim zdaniem to marny zysk w zestawieniu z korzyściami stosowania NHibernate. Pisząc nawet średniej wielkości systemy, które niejednokrotnie będzie trzeba modyfikować w procesie rozwoju oprogramowania dojdziesz do wniosku, że wspominany symboliczny zysk, który uzyskałeś jest nie wiele wart. Wychodzę z założenia, że dobrze zaprojektowany system (stabilny, elastyczny, etc..) to system dobrze zaprojektowany od początku do końca, dlatego jeśli to możliwe stosuję zazywczaj sprawdzone narzędzia typu NHibernate.

Nawet jeśli tworzysz w amatorskim warsztacie niewielkie aplikacje (5 użytkowników itp) to i tak uważam, że warto zacząć stosować narzędzia wykorzystywane przez przemysł by gromadzić cenne doświadczenie z nimi związane.

Odnośnie generowania plików konfiguracyjnych dla NHibernate to polecam zapoznać się z: http://fluentnhibernate.org/

--
Pozdrawiam
Marcin

@devils.namespace: Fluent NH jest swietny

@somekind: a co jak firma szybko urosnie i bedize chciala powiekszenia systemu? I co miesiac bedize miec 25% ludzi wiecej? i co miesiac bedzie dochodzic cos do bazy ?

Pzodrawiam.

devils.namespace napisał(a)

Nawet jeśli tworzysz w amatorskim warsztacie niewielkie aplikacje (5 użytkowników itp) to i tak uważam, że warto zacząć stosować narzędzia wykorzystywane przez przemysł by gromadzić cenne doświadczenie z nimi związane.

Ależ ja używam NHibernate! I używam tez Linq - bo lubię, bo często mi wystarcza, bo jestem przyzwyczajony.

Assassin napisał(a)

@somekind: a co jak firma szybko urosnie i bedize chciala powiekszenia systemu? I co miesiac bedize miec 25% ludzi wiecej? i co miesiac bedzie dochodzic cos do bazy ?

No to na dzień dobry powinienem powiedzieć klientowi, że system dla jego trzech pracowników będzie kosztował 10 mln zł, wliczając w to 2 serwery BD, 4 serwery WS i 4 dla aplikacji, własny system operacyjny i przeglądarkę internetową. Na wszelki wypadek, gdyby za 10 lat jego firma została międzynarodową korporacją. ;)

Gdy ktoś coś u mnie zamawia, to dobieram technologię do jego wymagań. Gdy okazuje się, że wymagania wzrastają i technologia im nie podoła, to ją zmieniam i klient za to płaci. Dla niego to też lepsze rozwiązanie - nie musi płacić większej kwoty na początku.

Dzięki Wam za linki, przyjrzę się im niebawem. :)