[.NET] Typed Dataset en XSD

[Scharnout]

Onlangs ben ik aan het experimenteren gegaan met Typed DataSets die vanuit XSD gegenereerd worden. Maakt het leven een stuk makkelijker in ieder geval. Maar nu ik zie tot mijn verstrooide verbazig dat ik het op twee verschillen manieren heb gedaan. Namelijk:

C#:

public UserDataSet UserDataSet()
{
    UserDataSet Temp = new UserDataSet();
    Temp.ReadXmlSchema("User.xsd");
    return Temp;
}

En 1 op de manier zoals beschreven in dit artikel:
http://authors.aspallianc...stronglytypeddataset.aspx

Nu wil ik graag weten of er nog verschil inzit. Op de tweede manier krijg ik er een hele dll bij, maar als dat sneller of efficienter doe ik dat graag natuurlijk. Of linkjes naar meer artikelen is ook goed

[sander_g]

Ik vraag me af of je in je voorbeeldcode wel echt een Typed DataSet onder handen hebt.
Een Typed DataSet is verpakt een .NET Class. UserDataSet zou dus al een class moeten zijn die je op een andere manier hebt opgemaakt, bijvoorbeeld via de Server Explorer van Visual Studio.

Je kunt het verschil merken wanneer je de een instantie van de Typed DataSet creëert en je velden in de dataset kunt refereren als ware het properties. Ik vermoed eigenlijk dat je dat met je UserDataSet code niet kunt (maar kan me vergissen hoor).

Als dat zo is, dan heb je geen Typed DataSet maar een gewone, en moet je velden benaderen via programmacode zoals

code:

 ds.Tables["Suppliers"].Columns["SupplierID"];

Een Typed DataSet kan je zo gebruiken:

code:

 ds.Suppliers.SupplierID;

Verder maakt niet zo veel uit of ie in een aparte dll zit of niet. Een aparte dll kan handig zijn als je 'm in andere projecten ook wilt gebruiken.

[whoami]

In je voorbeeld code heb je imo idd geen typed dataset, maar een dataset met een xsd schema.
Aan de hand van dat XSD schema, bepaal je dan ahw de layout van je dataset. Je legt dus, met die xsd, constraints op je dataset. Bv, de eerste column mag enkel numerieke waarden bevatten, ed...

[Scharnout]

Ik kan mijn kolommen wel aanroepen met dataset.table.columnname, maar ik begrijp uit het antwoord van whoami dat het niet een echte typed dataset is. Ik zal dus xsd.exe erop loslaten.

Welke vormen zou ik nog meer kunnen kiezen naast typed dataset?

Ik gebruik het nu voornamelijk omdat het veiliger is (geen sql-injection mogelijk). Ik gebruik het binnen een n-tier applicatie. De reden dat ik het vraag is omdat ik eefbe iets over entiteiten ipv datasets hoorde zeggen (binnen llbgenpro). Wat is dat bv?

[whoami]

Scharnout schreef op 06 October 2003 @ 11:22:
Ik kan mijn kolommen wel aanroepen met dataset.table.columnname, maar ik begrijp uit het antwoord van whoami dat het niet een echte typed dataset is. Ik zal dus xsd.exe erop loslaten.

Met jouw code-voorbeeld (het inladen van dat xsd), kan je dus bv dit schrijven:

code:

MyDataSet.Werknemers.Naam

Dan is het wel een typed dataset.

Ik gebruik het nu voornamelijk omdat het veiliger is (geen sql-injection mogelijk). Ik gebruik het binnen een n-tier applicatie. De reden dat ik het vraag is omdat ik eefbe iets over entiteiten ipv datasets hoorde zeggen (binnen llbgenpro). Wat is dat bv?

Een dataset kan je als een entiteit beschouwen.
Ik vermoed dat EfBe in z'n llblgen Pro geen gebruik maakt van DataSets , maar van custom objects.
Classes dus die de data representeren, en methods hebben om inserts/updates/deletes etc te doen.

En hoezo, er is geen SQL injection mogelijk? Omdat je gebruik maakt van een DataAdapter met gegenereerde SQL statements om data te gaan inserten/updaten?
Daarvoor hoef je niet perse (typed) datasets te gebruiken. Als je gebruik maakt van parameters in je SQL statements , dan ga je ook al SQL injection vermijden.

[EfBe]

Scharnout schreef op 06 October 2003 @ 11:22:
Ik kan mijn kolommen wel aanroepen met dataset.table.columnname, maar ik begrijp uit het antwoord van whoami dat het niet een echte typed dataset is. Ik zal dus xsd.exe erop loslaten.

Als je een table op een control/component sleept in vs.net maakt hij een xsd aan, EN een typed dataset. (die class hangt dan in de solution onder de xsd). Je kunt ze ook los genereren met xsd inderdaad.

Ik gebruik het nu voornamelijk omdat het veiliger is (geen sql-injection mogelijk).

Dat heeft er niet zoveel mee te maken hoor. typed datasets zijn prettiger omdat je niet myDS.Tables[0].Rows[0]["MyColumn"].ToString() hoeft te doen maar meteen via typed properties

Ik gebruik het binnen een n-tier applicatie. De reden dat ik het vraag is omdat ik eefbe iets over entiteiten ipv datasets hoorde zeggen (binnen llbgenpro). Wat is dat bv?

Ik gebruik custom classes (dus een gewone class) voor entities, die een DTO (data transfer object) in zich hebben voor de values (die plugt een DAO, data access object, er in). Ik gebruik typed dataTABLEs voor typed lists en typed views. typed datatable is ong als een typed dataset alleen genereer ik de code en niet MS' tooltje. (ik derive gewoon een class van DataTable). typed lists zijn lists van fields uit 1 of meerdere entities en typed views zijn maps van een db view op een class, in dit geval een class derived van datatable.

[Scharnout]

EfBe schreef op 06 October 2003 @ 11:54:
Ik gebruik custom classes (dus een gewone class) voor entities, die een DTO (data transfer object) in zich hebben voor de values (die plugt een DAO, data access object, er in). Ik gebruik typed dataTABLEs voor typed lists en typed views. typed datatable is ong als een typed dataset alleen genereer ik de code en niet MS' tooltje. (ik derive gewoon een class van DataTable). typed lists zijn lists van fields uit 1 of meerdere entities en typed views zijn maps van een db view op een class, in dit geval een class derived van datatable.

Voor User zou je dus een class User maken met properties Name en Address enzo en methods zoals select en insert en voor bv een nieuwe user instantieer je een nieuw object en geef je dat door over je lagen?

[EfBe]

Scharnout schreef op 06 October 2003 @ 12:17:
Voor User zou je dus een class User maken met properties Name en Address enzo en methods zoals select en insert en voor bv een nieuwe user instantieer je een nieuw object en geef je dat door over je lagen?

User heeft dan in zich een entityfields object, dat is een object dat puur entity field objects bevat (1 per field). Als de user moet worden gefetcht uit de database, dan creeert het user object een UserDAO instance en geeft aan de fetch routine die daar in zit de entityfields instance mee. Die wordt dan door de UserDAO gevuld.

Save idem dito.

Wil je een nieuwe user maken bv dan creeer je gewoon een nieuwe user class instance. Die is initieel leeg:

UserEntity newUser = new UserEntity();
// fill
newUser.Name = "EfBe";
newUser.EmailAddress="[e-mail]";
// etc.
// save. Will determine insert/update automatically
newUser.Save();

Omdat de code mbv templates wordt gegenereerd en voortbouwt op bestaande classes in een library (bv UserEntity is een derived class van EntityBase waar alle logica inzit die algemeen is voor alle entity classes), kun je ook templates maken die de adapter structuur volgen ala .net, dus bv:
UserDAO.Save(newUser); ipv newUser.Save();