[Alg/.NET] n-tier ontwikkeling / data transfer objects

[whoami]

Ik vraag me af welk 'model' jullie gebruiken voor n-tier ontwikkeling (al dan niet in .NET).

Gebruiken jullie de 'Table-module' (Fowler) aanpak, waarbij je vooral gebruik maakt van DataSets/DataTables en niet echt 'custom business-logic objects' hebt, of gebruiken jullie een meer OO - aanpak waarbij je custom business logic objects hebt (al dan niet met een data-mapper).

Als je voor de 2de aanpak kiest, gebruik je dan voor complexe situaties een 'data-mapper' (Fowler) of bevat je BL-object ook je data-access code (zie ook de aanpak in het boek Expert C# Business Objects van Rockford Lothka)?
(Zie ook deze link naar EfBe's weblog voor meer info over de verschillende manieren van aanpak).
Hoe ga je te werk met de data-mapper?
Bevat je BL-object een reference naar zo'n datamapper; bevoorbeeld:

code:

class MyBusinessObject
{
    private  IMyBusinessObjectDAL      _myObjDal;


    public void Save()
    {
           _myObjDal = DalFactory.GetMyBusinessObjectDAL();

           _myObjDal.Save ( .... );
    }

    public static MyBusinessObject Fetch( int id )
    {
           _myObjDal = DalFactory.GetMyBusinessObjectDAL();

           return new MyBusinessObject ( _myObjDal.Fetch(id));

    }

}

of verkies je om die data-mapper eerder in de client te gebruiken en daar de BL objecten te gaan 'consumen' ipv dat die data-mapper een member is van je BL-object?

Dan vraag ik me ook nog af wat je gebruikt als Data - transfer object om de communicatie tot stand te laten komen tussen de BL-object en de data-mapper, gebruik je hiervoor (typed) datasets/datatables/datarows, custom objecten, hashtables, iets anders.... ?

[Alarmnummer]

Dto`s gebruik je niet als communicatie tussen het bl object en de data-mapper, maar je gebruikt ze om objecten over het internet te kunnen sturen zonder vast te zitten aan een enorme lading calls.

[whoami]

Alarmnummer schreef op 14 oktober 2004 @ 09:36:
Dto`s gebruik je niet als communicatie tussen het bl object en de data-mapper, maar je gebruikt ze om objecten over het internet te kunnen sturen zonder vast te zitten aan een enorme lading calls.

Hoe doe je dan de communicatie tussen die 2 lagen?
Met een DTO kan het best makkelijk zijn, en, als je DAL remoted is, heb je geen probleem als je een dto gebruikt.

[Jabbah]

Ik ben (nog) niet bekend met de Fowler methode, maar in het project waar ik nu aan werk (wat bijna af is) doe ik het volgende:

Ik maak business objects (bv. Customer of Order) met hun properties en methodes om deze objecten te bewerken. Vervolgens maak ik een CustomerController object die dan de customer-gegevens uit de database ophaalt (of update, delete). Dit is meestal een static class met methode zoals FetchById, FetchAll, Update, etc.. De gegevens die ik opvraag retourneer ik altijd in een ArrayList. Een ArrayList kan je ook direct binden aan een DataGrid o.i.d. Als ik slechts 1 object opvraag, retourneer ik gewoon een instantie van dat object ipv een ArrayList met 1 object.

Deze controller classes kan ik dan naar een aparte dll compileren en gebruiken in al mijn applicaties.

Ik heb nog geen ervaring met andere methoden om de voor- en nadelen van mijn methode te zien, maar het werkt iig prettig.

btw, Ik werk in .NET.

[Alarmnummer]

whoami schreef op 14 oktober 2004 @ 09:37:
[...]
Hoe doe je dan de communicatie tussen die 2 lagen?
Met een DTO kan het best makkelijk zijn, en, als je DAL remoted is, heb je geen probleem als je een dto gebruikt.

Idd..als je business logic wel remote is zou dto misschien een oplossing kunnen zijn. Daar was ik niet vanuit gegaan.

[whoami]

Jabbah schreef op 14 oktober 2004 @ 09:44:
Ik maak business objects (bv. Customer of Order) met hun properties en methodes om deze objecten te bewerken. Vervolgens maak ik een CustomerController object die dan de customer-gegevens uit de database ophaalt (of update, delete). Dit is meestal een static class met methode zoals FetchById, FetchAll, Update, etc.. De gegevens die ik opvraag retourneer ik altijd in een ArrayList. Een ArrayList kan je ook direct binden aan een DataGrid o.i.d. Als ik slechts 1 object opvraag, retourneer ik gewoon een instantie van dat object ipv een ArrayList met 1 object.

Je controller classes (DAL) hebben dus weet van je business objects, aangezien die controllers dus je BL objecten creeëren en ze ook binnenkrijgen om ze te saven?
Je gebruikt dan ook zowel de 'controller' classes als de 'BL' classes in je client ?

[Jabbah]

whoami schreef op 14 oktober 2004 @ 10:16:
[...]

Je controller classes (DAL) hebben dus weet van je business objects, aangezien die controllers dus je BL objecten creeëren en ze ook binnenkrijgen om ze te saven?
Je gebruikt dan ook zowel de 'controller' classes als de 'BL' classes in je client ?

Helemaal correct.

Nou zijn er blijkbaar meerdere methoden om via je client je DAL en BL te benaderen. Is mijn eerder genoemde methode 'good practice'? Of levert deze methode de ervaren Microsoft mannen kromme tenen op? Het is op deze manier in ieder geval mogelijk op de DAL en BL in een toekomstig project te gebruiken, mits deze gebruik maakt van dezelfde database.

[Amras]

Ik heb zelf ook het boek Expert C# Business Objects van Rockford Lothka en heb m'n model ook enigzins van hem overgenomen. Hij zet echter zijn data access code ook in z'n business object en dat lijkt mij niet echt handig, vooral niet als je bijvoorbeeld in een database en in XML wilt opslaan. Verder krijg je zo enorme klassen en het voelt ook niet goed om die code in je business object te plaatsen.

Hoe heb ik het dan aangepakt? Ik heb voor ieder business object een data access object (Order / OrderDAO etc.). Een business object heeft onder andere de methode DAL_Create die het data access object gebruikt (m'n business object heeft geen reference naar het data access object), deze methode ziet er als volgt uit:

C#:

protected override void DAL_Create()
{
    OrderDAO dao = new OrderDAO();
    dao.Create(this);
}

Net als in het boek van Lothka houden mijn business objects bij of ze opgeslagen zijn in de database (IsDirty, IsNew etc.). Ieder business object heeft dan een public methode Save die aan de hand van de state bepaald welke DAL_xyz methode er moet worden aangeroepen. Zo kun je in je GUI gewoon Save() roepen tegen het business object en wordt alles netjes opgeslagen of verwijderd.

Ik moet bekennen dat ik me hier nog niet heel lang mee bezig hou, dus op- en aanmerkingen op deze manier van werken zijn erg welkom.

[whoami]

Jabbah:
De method die jij gebruikt wordt alleszins beschreven in een van MS best practice guides (Designing Data tiers and passing data through tiers).
Echter, ben ik meer een voorstander van de methode waarbij een Business Object de DAL 'gebruikt' (that is, een referentie heeft naar een DAL object), zodanig dat je de DAL niet rechtstreeks in je client aanspreekt. Het enige dat je dan in je client rechtstreeks aanspreekt is je BL object (misschien ben ik te puristisch, ik weet het niet).
Echter, ik vraag me dan af wat eigenlijk het beste is om de data van de ene laag naar de andere over te brengen.

[whoami]

Amras schreef op 14 oktober 2004 @ 10:43:

C#:

protected override void DAL_Create()
{
    OrderDAO dao = new OrderDAO();
    dao.Create(this);
}

Heb je hier geen cross-reference ? (Je BL heeft een reference naar je DAL assembly, en je DAL assembly heeft een reference naar je BL assembly ? )

[Amras]

whoami schreef op 14 oktober 2004 @ 10:47:
[...]

Heb je hier geen cross-reference ? (Je BL heeft een reference naar je DAL assembly, en je DAL assembly heeft een reference naar je BL assembly ? )

Ik zie niet echt wat je bedoelt, het data access object heeft geen reference naar m'n business object. Die Create method zet de data in de database en doet er verder niks mee.

[whoami]

Amras schreef op 14 oktober 2004 @ 10:51:
[...]


Ik zie niet echt wat je bedoelt, het data access object heeft geen reference naar m'n business object. Die Create method zet de data in de database en doet er verder niks mee.

Het object dat je meegeeft aan de database (this), is dus je BL object. Je DAL code heeft dat nodig om die waarden in de DB te kunnen zetten.
Je assembly (dll) die dus je DAL class bevat, heeft dus een reference naar de assembly die je BL object bevat.
Aangezien je vanuit je BL object je DAL class gebruikt, zal je DLL waarin je BL objecten zitten, ook een reference hebben naar je DLL met DAL classes.
(Tenzij je BL en DAL classes in dezelfde DLL zitten?).

[Jabbah]

Misschien een domme vraag, maar heeft je DAL niet altijd een referentie nodig naar je object? Ik bedoel, als je een object wilt opslaan in de database, dan moet je DAL toch bekend zijn met dat object? Hoe moet deze anders weten welke waardes er opgeslagen moeten worden?

whoami: je zegt dat je de DAL niet gebruikt in je client, maar in je object. Wat nou als je een aantal objecten wilt opvragen via je DAL (bv. alle orders van een bepaalde datum). Ga je dan via 1 buesiness object de juiste methode in je DAL aanroepen en vervolgens via datzelfde business object het resultaat weer teruggeven aan de client? Klinkt me een beetje vreemd in de oren. Hoe los je dat dan op?

[gorgi_19]

Misschien een domme vraag, maar heeft je DAL niet altijd een referentie nodig naar je object? Ik bedoel, als je een object wilt opslaan in de database, dan moet je DAL toch bekend zijn met dat object? Hoe moet deze anders weten welke waardes er opgeslagen moeten worden?

Tenzij je DAL bestaat uit DataTables en je met typed datasets aan de gang gaat en er bijvoorbeeld in een Business Facade eea omgezet wordt. Typed datasets willen nog wel voorkomen.

[whoami]

Jabbah schreef op 14 oktober 2004 @ 11:03:
Misschien een domme vraag, maar heeft je DAL niet altijd een referentie nodig naar je object? Ik bedoel, als je een object wilt opslaan in de database, dan moet je DAL toch bekend zijn met dat object? Hoe moet deze anders weten welke waardes er opgeslagen moeten worden?

Eigenlijk mag je DAL niets afweten van je BL layer.

whoami: je zegt dat je de DAL niet gebruikt in je client, maar in je object. Wat nou als je een aantal objecten wilt opvragen via je DAL (bv. alle orders van een bepaalde datum). Ga je dan via 1 buesiness object de juiste methode in je DAL aanroepen en vervolgens via datzelfde business object het resultaat weer teruggeven aan de client? Klinkt me een beetje vreemd in de oren. Hoe los je dat dan op?

Je kan een BusinessLogic Object 'OrdersCollection' hebben, die je OrderDAL object aanspreekt.
bv:

code:

OrdersCollection coll = OrdersCollection.Fetch (aDate);

De Fetch van je OrdersCollection roept je dal object aan:

code:

OrdersCollection Fetch( DateTime d )
{
    DataSet ds = OrdersDAL.GetOrdersFromDate (d);

     OrdersCollection coll = new OrdersCollection();

     foreach( DataRow dr in ds.Tables[0].Rows )
     {
          coll.Add ( new OrderInfo( dr.OrderDate, dr. .... ));
     }

     return coll;

}

De OrdersCollection bevat hier OrderInfo objecten (dat kan een inner class zijn) die enkel 'read only' velden bevat van je orders. Een OrderInfo object bevat niet alle gegevens van één order, maar enkel die gegevens die belangrijk zijn voor de collectie (bv, orderid (zodat je dan later het volledige order kunt ophalen), orderdatum, naam v/d klant die het order geplaatst heeft).

[ Voor 13% gewijzigd door whoami op 14-10-2004 11:12 ]

[gorgi_19]

whoami schreef op 14 oktober 2004 @ 11:10:
Eigenlijk mag je DAL niets afweten van je BL layer.

Was dit niet andersom? Een BLL hoeft niets af te weten van de DAL; als die z'n data maar terugkrijgt. Hoe, of bij wijze van spreke welke assembly deze aanlevert, zal hem een zorg zijn. Mits het maar volgens vaststaande procedures aangeleverd wordt.

[whoami]

gorgi_19 schreef op 14 oktober 2004 @ 11:12:
[...]

Was dit niet andersom? Een BLL hoeft niets af te weten van de DAL; als die z'n data maar terugkrijgt. Hoe, of bij wijze van spreke welke assembly deze aanlevert, zal hem een zorg zijn. Mits het maar volgens vaststaande procedures aangeleverd wordt.

Ik ga er altijd van uit dat een laag niets hoeft af te weten van de laag die zich boven die laag bevindt.
Bv, een Presentatie laag heeft een reference naar de assembly met de BL objecten, de BL laag heeft een referentie naar de assembly met de DAL classes en niet andersom.

[Amras]

whoami schreef op 14 oktober 2004 @ 11:14:
[...]


Ik ga er altijd van uit dat een laag niets hoeft af te weten van de laag die zich boven die laag bevindt.
Bv, een Presentatie laag heeft een reference naar de assembly met de BL objecten, de BL laag heeft een referentie naar de assembly met de DAL classes en niet andersom.

Hier ben ik het wel mee eens, ik zie alleen niet hoe ik m'n business objects kan opslaan als ik deze niet aan m'n data access object mag geven (zonder een referentie naar het business object op te slaan). Hoe zou je dat dan aanpakken?

[whoami]

Amras schreef op 14 oktober 2004 @ 11:24:
[...]


Hier ben ik het wel mee eens, ik zie alleen niet hoe ik m'n business objects kan opslaan als ik deze niet aan m'n data access object mag geven (zonder een referentie naar het business object op te slaan). Hoe zou je dat dan aanpakken?

Dat was dus wat ik ook vroeg in m'n topicstart.
Wat gebruik je als DTO (Data Transfer Object) om je gegevens tussen 2 lagen te versluizen.

[RSchellhorn]

gorgi_19 schreef op 14 oktober 2004 @ 11:12:
[...]

Een BLL hoeft niets af te weten van de DAL; als die z'n data maar terugkrijgt.

Ik gebruik deze methode ook, omdat ik van mening ben dat een business object niet boven zijn data access object staat, maar eerder er onder. De DAL zorgt voor syncronisatie van je geheugen (BOL) met de database bijvoorbeeld. Je zou dus ook kunnen zeggen, dat de BOL een soort van cache en OO representatie is voor je database.

In mijn huidige project (java) heb ik vier packages, namelijk:
- De bol (staat geheel op zichzelf)
- Een abstracte dal factory
- Een database dal implementatie
- Een command package

De DAL retrieved records en zet deze om in business objecten. Bovendien registreert het data access object zich via het Observable-Observer pattern bij de dal om op de hoogte gesteld te worden van wijzigingen, die een update in de DAL veroorzaken.

De command objecten zorgen voor de 'koppeling'. Dus de retrieve, creates en deletes van business objecten.

Hierarchies ziet het er dus meer zo uit:
Command
DAL |
___BOL

Wellicht is het argument hiertegen dat het niet een 100% lagen structuur is. Toch vind ik dit een praktische en elegante oplossing, met als grootste pre dat de BOL geheel los komt van de rest van het programma.

[ Voor 5% gewijzigd door RSchellhorn op 14-10-2004 11:43 . Reden: al die typos ]

[Not Pingu]

whoami schreef op 14 oktober 2004 @ 09:11:
bevat je BL-object ook je data-access code (zie ook de aanpak in het boek Expert C# Business Objects van Rockford Lothka)?

Voor project(en/tjes) die toch alleen maar van een database gebruik gaan maken, doe ik het idd zo: custom classes en een business layer die de data-aanroep doet en de data omzet naar de desbetreffende classes. Eventueel een datahelper classe daaronder die verschillende typen databases kan aanspreken.

Maar als je je input heel breed wilt houden, van database tot xml, dan kun je beter met een Provider-achtige interface werken die door datahelpers voor elke verschillende databron wordt geimplementeerd. Probleem is dan: hoe lever je data aan de business layer voor vertaling naar je business objects? Datasets zijn een universeel toepasbare oplossing maar vreten teveel resources. Das nou juist de reden dat je custom objects gebruikt.

[whoami]

De reden dat je custom objects gebruikt voor je business logica ligt niet zozeer in het 'minder vreten van resources tov datasets', maar ook dat je daar veel meer vrijheid hebt (lazy loading, inheritance, strategy pattern, ... )

[alienfruit]

Waarom kijk je niet eens na de oplossing van RemObjects, als ik je goed begrijp hebben ze wel zoiets waarmee je bezig bent. Mooie linkje er bij.

[whoami]

Plaats je trouwens je domain objecten en je DAL objecten op de server, plaats je je domain objecten bij de client en je DAL op de server, hoe doe je het?

[whoami]

Ik ben er nog altijd niet goed uit hoe ik het nu best zou aanpakken.

M'n business logic zou op de server moeten draaien zodanig dat het makkelijk is om een nieuwe versie van de BL te deployen.
Echter, als de BL in m'n objecten bevat zit, dan moet ik ook die ge-update versie doorgeven naar de clients. Dat wil ik dus niet.
Misschien moet ik dan maar een remoted object maken die de business logic bevat, en werken met 'domme' objecten die serializable zijn en dus kunnen doorgegeven worden naar de Business Logic 'Service' layer ofzo.
De client hoeft dan enkel een assembly te hebben met de interfaces waaraan de remoted BL-service objecten aan voldoen, en moeten dan ook een assembly hebben waarin de 'domme' objecten in zitten.
Eigenlijk wringt dat een beetje bij mij, aangezien je niet meer echt 'encapsulated' werkt. Een object (klant) kan niet meer zelf nagaan of hij bv. van een bepaalde korting kan genieten, daar zal een remote call voor nodig zijn. Hier moet je dan ook nog eens oppassen dat je niet teveel (onnodige) remote - calls gaat gaan doen.

Het puurste is eigenlijk dat je business logica ook daadwerkelijk in je BL objecten vervat zit, en dat die BL objecten zelf een call kunnen doen naar een remoted DAL object om zichzelf te saven/ophalen in de DB. Echter, dit kan je enkel doen als je BL niet veranderd; ik denk dus niet dat dit een geschikte aanpak is voor een enterprise application.

[EfBe]

whoami schreef op 15 oktober 2004 @ 10:26:
Ik ben er nog altijd niet goed uit hoe ik het nu best zou aanpakken.

Wat lijkt je het meest PRAKTISCHE? Je kunt een hele 'pure' boom maken met weet ik wat voor objecten en een vuistdikke manual waarin staat waarom het precies zo is, maar als een andere ontwikkelaar die manual nodig heeft om een vertaling te maken tussen theoretische business process definitie en jouw code (i.e.: het terugvinden waar een business process fysiek is geimplementeerd) is het wellicht praktischer om het anders aan te pakken, bv een situatie waarin een business process geimplementeerd is zoals het ook is gedefineerd, bv in een aparte class die entity objects (zonder BL) consumeert.

Het puurste is eigenlijk dat je business logica ook daadwerkelijk in je BL objecten vervat zit, en dat die BL objecten zelf een call kunnen doen naar een remoted DAL object om zichzelf te saven/ophalen in de DB. Echter, dit kan je enkel doen als je BL niet veranderd; ik denk dus niet dat dit een geschikte aanpak is voor een enterprise application.

Hoeft niet, je O/R mapper kan dit ook regelen omdat je BL object gecontrolleerd wordt door de O/R mapper, dus het BL object leest gewoon zn Orders collectie en die wordt dan door de O/R mapper opgehaald bv.

Ik moet wel zeggen dat ik het echt niet begrijp waarom mensen domain driven design zo geweldig vinden. Het punt is nl. dat, en dat heeft Evans zelf ook toegegeven met de opmerking dat er een vertaalslag nodig is tussen het theoretische business process en de domain objects die het representeren in code, het essentieel is dat er een sterke verbinding bestaat tussen theoretische onderbouwing (dus de theorie achter het business process, hoe is het gemodelleerd in functionaliteit, tenslotte automatiseert een automatiseringsprocess een businessprocess normaliter) en fysieke realisatie, zodat je vanuit je fysieke realisatie de theoretische onderbouwing makkelijk kunt terugvinden (en dus weet waarom het zo is gerealiseerd) en andersom idem dito, wanneer het business process wijzigt, je middels een wijziging in de theorie van het business process top down naar je code kunt 'drillen' en zo alle code op de juiste manier kunt aanpassen.

Note: een uml model van je classes is GEEN theoretisch model van een proces.

Vergeet nooit dat Fowler dicht bij de agile/XP movement staat, die ervan uitgaan dat theorie achter een heel proces en een heel theoretisch ontwerp niet te diep moet gaan. Ik denk dat dat geen toeval is.

[ Voor 3% gewijzigd door EfBe op 15-10-2004 11:06 ]

[whoami]

EfBe schreef op 15 oktober 2004 @ 11:03:
...
praktischer om het anders aan te pakken, bv een situatie waarin een business process geimplementeerd is zoals het ook is gedefineerd, bv in een aparte class die entity objects (zonder BL) consumeert.

Zoiets zoals ik dus in m'n vorige post beschreven heb?
Ik denk dat dit inderdaad de beste / meest praktische manier is voor enterprise app's met BL die vaak kan wijzigen.

Hoeft niet, je O/R mapper kan dit ook regelen omdat je BL object gecontrolleerd wordt door de O/R mapper, dus het BL object leest gewoon zn Orders collectie en die wordt dan door de O/R mapper opgehaald bv.

Je bedoeld hier dat die O/R mapper in dit geval een 'manager class' is, die je entity object (object zonder BL) gaat gaan 'populaten', en dat er daar business logica uitgevoerd wordt?

Ik moet wel zeggen dat ik het echt niet begrijp waarom mensen domain driven design zo geweldig vinden.

Mjah, misschien omdat dit de meest OO manier is.
Ik denk dat dit enkel kan toegepast worden als je je BL objecten op de client kunt plaatsen.

[EfBe]

whoami schreef op 15 oktober 2004 @ 11:37:
[...]
Zoiets zoals ik dus in m'n vorige post beschreven heb?
Ik denk dat dit inderdaad de beste / meest praktische manier is voor enterprise app's met BL die vaak kan wijzigen.

Ja, je centraliseert de BL dan, wat makkelijker is.

Je bedoeld hier dat die O/R mapper in dit geval een 'manager class' is, die je entity object (object zonder BL) gaat gaan 'populaten', en dat er daar business logica uitgevoerd wordt?

In het BL object zit BL logica, die heeft bv related objects nodig, hij maakt dan gebruik van de lazy loading code van de O/R mapper door via zichzelf de related objects op te halen.

[...]
Mjah, misschien omdat dit de meest OO manier is.

Dat is IMHO de minst interessante reden die er is. Dat iets in een bepaalde methodiek is gemaakt boeit IMHO helemaal niet. Net zo min welke taal gebruikt wordt. Iets doen omdat het het meest OO is, is de methodiek verheffen boven wat je werkelijk aan het maken bent, een boek schrijven met louter mooie zinnen maar 0.0 verhaal zeg maar.

[whoami]

Alarmnummer schreef op 14 oktober 2004 @ 10:12:
[...]

Idd..als je business logic wel remote is zou dto misschien een oplossing kunnen zijn. Daar was ik niet vanuit gegaan.

Als je BL remote is, dan heb je natuurlijk ook iets nodig op de client om je objecten in voor te stellen. Zijn die objecten dan enkel 'data-bags' zonder logic ?

Amras schreef op 14 oktober 2004 @ 10:43:

Hoe heb ik het dan aangepakt? Ik heb voor ieder business object een data access object (Order / OrderDAO etc.). Een business object heeft onder andere de methode DAL_Create die het data access object gebruikt (m'n business object heeft geen reference naar het data access object), deze methode ziet er als volgt uit:

C#:

protected override void DAL_Create()
{
    OrderDAO dao = new OrderDAO();
    dao.Create(this);
}

Ik moet bekennen dat ik me hier nog niet heel lang mee bezig hou, dus op- en aanmerkingen op deze manier van werken zijn erg welkom.

Hoe ga jij hier tewerk met transactions ? Waar initieer je een transactie en commit of rollback je ze ?
Stel dat je een Customer object hebt, en een CustomerDAO object. Een Customer heeft een Orders Collectie, en je hebt dus ook een OrderDAO object.
Hoe ga je die Customer en z'n orders naar de DB gaan schrijven binnen 1 transactie ?
En als je DAL remoted is, ga je dan iedere keer een nieuw remoted DAO object gaan maken ?

Gunp01nt schreef op 14 oktober 2004 @ 14:35:
[...]


Voor project(en/tjes) die toch alleen maar van een database gebruik gaan maken, doe ik het idd zo: custom classes en een business layer die de data-aanroep doet en de data omzet naar de desbetreffende classes. Eventueel een datahelper classe daaronder die verschillende typen databases kan aanspreken.

Maar als je je input heel breed wilt houden, van database tot xml, dan kun je beter met een Provider-achtige interface werken die door datahelpers voor elke verschillende databron wordt geimplementeerd. Probleem is dan: hoe lever je data aan de business layer voor vertaling naar je business objects? Datasets zijn een universeel toepasbare oplossing maar vreten teveel resources. Das nou juist de reden dat je custom objects gebruikt.

Kan je dit even wat meer toelichten aub ?

[ Voor 3% gewijzigd door whoami op 27-10-2004 10:03 ]

[Not Pingu]

whoami schreef op 27 oktober 2004 @ 09:49:
Kan je dit even wat meer toelichten aub ?

Weet niet precies wat je toegelicht wilt hebben, maar ok:

Bij een project waar ik meerdere dbms'en wilde ondersteunen, en waarbij andere databronnen niet nodig waren, heb ik een datahelper class geschreven die door de DAL wordt gebruikt om data op te halen. De DAL voert de datahelper class een SQL query (zolang je het simpel houdt zijn die queries goed cross-platform) en maakt adhv. een appsetting in de web.config een OleDb-, Odbc- of SqlConnection aan.
Dit werkt tot nu toe goed bij switchen tussen Acess, Sql Server en MySql.

Als je toch meer databronnen wilt ondersteunen, bijv. een XML file of user input of weetikveel wat, krijg je snel dat je veel dubbele code hebt omdat je de vertaling van de datainput naar de gewenste classes voor elke databron opnieuw moet schrijven. Zolang je alleen met databases werkt kun je gebruikmaken van de IDataReader interface om je DAL op welke dbms dan ook te laten aansluiten, maar als je ook XML of CSV files wilt lezen gaat dat al niet meer op. Om te voorkomen dat je de vertaalmethods voor elke databron opnieuw moet schrijven, kun je alle databronnen hun data in een dataset laten pleuren en die doorsturen naar de vertaalmethod.

Maar nu vertel ik vast niks nieuws want ik ben pas een jaartje bezig met .Net en anderen hier al veel langer.

[Amras]

whoami schreef op 27 oktober 2004 @ 09:49:
Hoe ga jij hier tewerk met transactions ? Waar initieer je een transactie en commit of rollback je ze ?
Stel dat je een Customer object hebt, en een CustomerDAO object. Een Customer heeft een Orders Collectie, en je hebt dus ook een OrderDAO object.
Hoe ga je die Customer en z'n orders naar de DB gaan schrijven binnen 1 transactie ?
En als je DAL remoted is, ga je dan iedere keer een nieuw remoted DAO object gaan maken ?

Ik ben een beetje het boek van Rockford Lhotka aan het volgen en ik gebruik zijn methodiek en pas deze aan als ik denk dat het handiger kan. Bij het gedeelte van transacties ben ik nog niet aangekomen, maar ik heb even doorgebladerd en zie dat hij zijn transacties maakt, commit en 'rollbackt' in zijn business objects zelf. Aangezien ik geen data access code in m'n business objects schrijf zal dat wel niet zo gaan gebeuren, maar tips en duwtjes in de goede richting zijn zeker welkom.

Het is inderdaad niet de bedoeling dat bij iedere Create, Update etc. een nieuw data access object wordt gemaakt. Die zal later netjes door de, eventueel remoted, DAL geleverd worden.