[ASP.net, C#] Trennung von Logik udn Benutzerschnittstelle

[Hardwaretoaster]

Ich habe mich jetzt ein wenig in die Materie eingelesen und wenn ich alles in eine Datei klatsche, dann bekomme ich das, was ich ungefähr haben will als ersten Entwurf zusammen. Nun stellt sich mir die Frage nach 'ner Architektur: Kann ich das irgendwie in Klassen trennen und trotzdem noch die Bequemlichkeit von Komponenten wie der SqlDataSource nutzen (ich habe es mal versucht von hand zu instanzieren, aber die DataSourceID Objektübergreifend im GridView setzen...ich hab's zumindest nicht hinbekommen)? Das gibt's bestimmt irgendwie, nur ich suche nach dem falschen Begriff...:(

[Unfug]

Meinst Du sowas wie MVC oder PAC?

[Hardwaretoaster]

Prinzipiell ja, aber ich würde halt gerne die fertigen Controls weiternutzen.

[Gast]

MVC kann man schon immer selbst implementieren trotz des jetzt erhältlichen ASP.NET MVC Framework. Allerdings ist die SqlDataSource eigentlich etwas quick&dirty und erlaubt keine richtige Trennung in Präsentation, Geschäftslogik und Datenzugriffslogik. Stattdessen kannst du aber das ObjectDataSource Control verwenden und dort eigene Objekte dran binden.

[Hardwaretoaster]

Argh, warum verführt man die Leute dann mit solchen Komponenten...
Und was nehme ich dann im Hintergrund in dem Objekt um die Datenbankverbindung zu machen am besten?

[Gast]

Argh, warum verführt man die Leute dann mit solchen Komponenten...
Und was nehme ich dann im Hintergrund in dem Objekt um die Datenbankverbindung zu machen am besten?

Da gibt's unterschiedliche Möglichkeiten:
- du schreibst deine Datenzugriffsklassen von Hand bzw. baust dir dafür Helferklassen.
- du lässt dir von VS.NET typisierte DataSets und TableAdapter generieren (mache ich oft)
- du verwendest Linq-Sql
- du verwendest das neue ADO.NET Entity Framework
- du verwendest irgend eine andere fertige Komponente wie z.B. die Enterprise Library

Wenn man's ganz genau nimmt, dann bindest du an die ObjektDataSource ein Geschäftsobjekt und dieses wiederum sollte auf ein Datenzugriffsobjekt zugreifen, das sich dann eben um die Datenbankkommunikation kümmert.

Aber nimm das blos nicht zu dogmatisch, auch wenn dir das immer ein paar Leute einreden wollen. Wenn für dein Szenario die SqlDataSource ausreicht, dann nimm sie. Wenn du jetzt mehrere SqlDataSourcen hast, die die gleichen Statements/Sprocs ausführen, dann kannst du dir überlegen, diese Logik in ein eigenes Objekt zu kapseln und an eine ObjectDataSource zu binden.

[Hardwaretoaster]

Hm, der einfachste Weg erscheint mir aktuell noch die SqlDataSource:
Ich habe eine Dropdownliste, die von einer befüllt wird, die Tabelle, die dort ausgewählt wird, wird zum Bearbeiten in ein Grid geladen. Dazu kommt noch eine, mit der ich ich im Data Dictionary auslese wo Constraints o.ä. draufliegen.
Vielleicht ein bisschen Pseudostruktur über weitere Partial Classes, ist das gangbar?

[Matrix316]

Also, wir machens hier meistens so, dass wir ne Klasse haben xyz und in dieser greifen wir auf die DB zu:


public DataSet getBenutzer(Int64 ID)
{
string strCN = ConfigurationManager.AppSettings["ConnectionString"];
SqlConnection myCon = new System.Data.SqlClient.SqlConnection(strCN);
SqlDataAdapter myDataAdapter = new System.Data.SqlClient.SqlDataAdapter();
SqlCommand mySelectCommand = new System.Data.SqlClient.SqlCommand();
DataSet myds = new DataSet("tbl_Benutzer");

String strSql = "";

strSql += " and Geloescht = 0";

try
{
myCon.Open();
mySelectCommand.Connection = myCon;
myDataAdapter.SelectCommand = mySelectCommand;
mySelectCommand.CommandText = "select * from tbl_Benutzer where UserID=" + ID.ToString() + strSql;
myDataAdapter.Fill(myds, "tbl_Benutzer");
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}
finally
{
myCon.Close();
}
return myds;
}

ConfigurationManager.AppSettings["ConnectionString"];

=

Connection String in Web.Config wo dann halt sowas drin steht:

<add key="ConnectionString" value="data source=SERVER;initial catalog=DATENBANKTABELLE;user id=sa;Password=PASSWORT"/>

Vor meiner Zeit wurden auch noch über spezielle VS DataSets und Stored Procedures die Daten aus der DB geholt, aber wenn man da was ändern will, sucht man sichn Wolf...

[Hardwaretoaster]

Also, wir machens hier meistens so, dass wir ne Klasse haben xyz und in dieser greifen wir auf die DB zu:


public DataSet getBenutzer(Int64 ID)
{
string strCN = ConfigurationManager.AppSettings["ConnectionString"];
SqlConnection myCon = new System.Data.SqlClient.SqlConnection(strCN);
SqlDataAdapter myDataAdapter = new System.Data.SqlClient.SqlDataAdapter();
SqlCommand mySelectCommand = new System.Data.SqlClient.SqlCommand();
DataSet myds = new DataSet("tbl_Benutzer");

String strSql = "";

strSql += " and Geloescht = 0";

try
{
myCon.Open();
mySelectCommand.Connection = myCon;
myDataAdapter.SelectCommand = mySelectCommand;
mySelectCommand.CommandText = "select * from tbl_Benutzer where UserID=" + ID.ToString() + strSql;
myDataAdapter.Fill(myds, "tbl_Benutzer");
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.Message);
}
finally
{
myCon.Close();
}
return myds;
}

ConfigurationManager.AppSettings["ConnectionString"];

=

Connection String in Web.Config wo dann halt sowas drin steht:

<add key="ConnectionString" value="data source=SERVER;initial catalog=DATENBANKTABELLE;user id=sa;Password=PASSWORT"/>

Vor meiner Zeit wurden auch noch über spezielle VS DataSets und Stored Procedures die Daten aus der DB geholt, aber wenn man da was ändern will, sucht man sichn Wolf...

und das Dataset kann man dann an Grids, etc übergeben, richtig? Das klingt nicht schlecht. Ohne, dass man zu viel drumherum konstruiert für eine recht kleine Anwendung

[Matrix316]

Genau. Kannste an Grids übergeben und wenn sich jetzt die Tabelle ändert, passiert garnix, weil mit select * du eh alle Felder bekommst. Oder wenn man die Spalten direkt auswählt, muss man nur die Abfrage ändern. Und wenn du global auf den DataSet zugreifen willst, kannste ihn einer Session Variable zuweisen.