C# i SQL Logowanie do rożnych Formatek

Witam
mam taki mały problem
zrobiłem logowanie w c# z wykorzystaniem bazy sql
wsi śmiga jak ta lala
ale.......
chce aby powiedzmy adinistrator po zalogowaniu sie logował sie do swojego okna
a pracownik do swojego
teraz loguje sie tylko do 1
prosze o porade jak to rozdzielic aby tak sie dało

wklejam kawałek kodu gdzie nastepuje porownanie danych z textboxa i bazy
oraz polecenie otwarcia formatki pracownika

if((text_user.Text == dro["user_Name"].ToString()) || (text_password.Text == dro["user_Password"].ToString()))
                {
                    Form_principal p = new Form_principal();
                    p.Show();
                    this.Hide();
                }
            }

            catch{

                MessageBox.Show("złe haslo");
            }

            finally{
            
            
            }


        }

ja bym to widział tak ze admin ma stały login powiedzmy "admin" i tylko haslo jest istotne we wlaczaniu odpowiedniej formatki
a w innym razie wyswietla sie formatka pracownikow

Każdy użytkownik może mieć w bazie zapisany typ startowej formatki. Obiekt tego typu powołasz do życia dynamicznie. Może to być dowolny typ (dziedziczący z Form) lub implementujący jakiś interfejs IStartingForm.

Zarówno użytkownik Janek, jak i Stefan mogą być adminami. Warto byłoby wiedzieć który admin co zmodyfikował konkretnie, a nie ogólnie że był to admin. Więc pomysł z jednym loginem admin jest delikatnie mówiąc słaby.

To jak zrobiłeś logowanie woła o pomstę do ... czegoś tam w co wierzysz. Do bazy przekazujesz login i hasło (a lepiej hash hasła) i porównujesz z danymi w bazie, jeśli się zgadza, to zwracasz dane potrzebne do wypełnienia obiektu usera: imię, nazwisko, login, pesel, rola, uprawnienia, ... Ale nie HASŁO!!!

wiem wiem
ale to nie jest profesionalna aplikacja
wiec bezpieczenstwo tu nie ma zadnego znczenia.

a dalo by sie na podstawie tego ifa zrobić przekazywanie na from 1 lub form 2
niechce nic wiele w kodzie zmieniac bo męczyłem sie z errorami dosyc długo ;]

sorki za orty ale nie jestem polonistą :)

Na podstawie samego login i pass pewnie ciężko wywnioskować rolę użytkownika ;)
W bazie w rekordzie usera (lub bardziej skomplikowana struktura) powinna być informacja o roli, np. A (jak admin), U (jak zwykły user). Jeśli zweryfikowałęś że user poprawnie się zalogował, to sprawdzasz rolę. Jeśli admin pokazujesz mu formę AdminForm, jeśli zwykły user, to UserForm. Chociaż jak pisałem ja trzymałbym jakiś typ formatki jaki pokazać lub nawet typ obiektu (klasę) i dynamicznie go tworzył.
Typ formatki (a nie konkretna klasa) ma tą zaletę że można stworzyć mechanizm gdzie przez zmianę biblioteki zmieniasz jaka fizycznie kontrolka się tworzy. Zapisując jaki typ (klasę) masz pokazać dla jakiej roli musisz zawsze umieć ten typ dostarczyć.

no zawsze mogę zrobić tak ze admin musi sie zalogować do głównego okna programu i dopiero stamtad przechodzi do swojego profilu
ale to trochę mało profesionalne wiec wolałbym tego uniknąć

Dobra najprościej, co ociera się o jakiś profesjonalizm:

1. w bazie masz informację o roli użytkownika: A,U
2. pobierając usera, pobierasz też rolę

Form userForm = null;
if(user.Role == "A")
  userForm = new AdminForm();
else
  userForm = new UserForm();

if (userForm != null)
{
  userForm.Show();
  this.Hide();
}
else
  MessageBox("błąd");

tomekb1987 napisał(a)

sorki za orty ale nie jestem polonistą :)

To trzeba być polonistą, żeby nie robić błędów? Debilne tłumaczenie.

tomekb1987 napisał(a)

ale to nie jest profesionalna aplikacja

tomekb1987 napisał(a)

ale to trochę mało profesionalne wiec wolałbym tego uniknąć

Może ustalcie ze sobą spójną wersję zeznań, bo za każdym razem piszecie co innego i trudno się do tego odnieść.

Profesjonalnie robi się to tak, że typy ról użytkowników są w oddzielnej tabeli (bo może ich być więcej niż dwie), a w jeszcze innej tabeli jest powiązanie użytkownika z rolą (bo jeden użytkownik może pełnić wiele ról).
Można też zrezygnować z tych tabeli, jeśli role są na stałe i przechowywać je jako suma flag w jednym z pól tabeli. Np. użytkownik o rolach: 1, 4 i 16 będzie miał wartość tego pola równą 21.
W rozwiązaniu 1 do informacji o rolach po stronie aplikacji dobiera się odczytując je z odpowiednich właściwości obiektów, natomiast w rozwiązaniu drugim po prostu sprawdza się flagi zdefiniowanego w aplikacji enuma, który opisuje te role. Jak widać rozwiązanie 2. jest znacznie prostsze.
Następnie, aplikacja sprawdza informacje o rolach i w zależności od nich otwiera odpowiednie okna, kontrolki, dodaje/usuwa pozycje z menu, itp.