[C# / OOD] Verstandige opzet DAL object?

[Verwijderd]

In het kader van wat .NET zelfstudie ben ik een eenvoudig multitier systeempje in ASP.NET aan het opzetten. Voor een business object Client heb ik een corresponderend DAL object aangemaakt:

C#:

     public class ClientDAL : IDataAccess<Client>
    {
        List<Client> clients = new List<Client>();

        #region constructors
        public ClientDAL(List<Client> clients)
        {
            this.clients = clients;
        }
        public ClientDAL()
        {
            this.clients = this.GetAll();
        }
        public ClientDAL(string sqlSelectQuery)
        {
          this.clients = this.GetAll(sqlSelectQuery);
        }
        #endregion

        #region interface 
        public List<Client> GetAll()
        {
                // clients list vullen met client objecten
        }
        public List<Client> FindAll(Predicate<Client> match)
        {
            return clients.FindAll(match);
        }

        [ .. etc .. ]

De functie GetAll() bijvoorbeeld populeert het clients object met alle klanten uit de database en paast dit object via een return statement naar de caller. Is dit een verstandig ontwerp? Punten waar ik bijvoorbeeld aan denk:

• Is de List<Client> clients een verstandige ontwerpkeuze? Of kan ik het DAL object beter stateless maken? En dan bij functies als FindAll ook een strongly typed list als input parameter meegeven?

[ Voor 29% gewijzigd door Verwijderd op 08-07-2005 17:38 ]

[Verwijderd]

_{Staat er niemand te springen om even zn licht erover te laten schijnen?}

[Alarmnummer]

Verwijderd schreef op donderdag 07 juli 2005 @ 15:43:
De functie GetAll() bijvoorbeeld populeert het clients object met alle klanten uit de database en paast dit object via een return statement naar de caller.

Het probleem aan deze aanpak is dat nadat de list met personen is geupdate, dit niet weer gebeurt. Dus het systeem blijft met dezelfde set data werken.. Dit zou taak moeten zijn van de or-mapper (het cachen). Die kan het ook meteen goed regelen mbt transacties en concurrent use.

Blader maar eens wat over DAO (Data Access Object) ontwerp. DAL = een 100% .NET kreet.. De rest van de wereld (Java ) gebruikt altijd DAO. Maar principe komt overeen (denk ik)..

[ Voor 5% gewijzigd door Alarmnummer op 08-07-2005 17:44 ]

[PrisonerOfPain]

Overigens geef je nogsteeds een Sql statement door aan je contructor, lijkt mij een breuk in je scheiding. Persoonlijk gebruik ik DAO's, zoals Alarmnummer hierboven ze al aanhaald, om een complete abstractie te hebben van alles wat met de database te maken heeft. (Sql, verbinding opzetten etc.) Ongeveer naar het voorbeeld van het DAO examples project op sourceforge.

[whoami]

Het probleem bij dat DAO example (zoals ik het nu zo snel zie), is dat die DAO blijkbaar ook de verantwoordelijkheid op zich neemt om de transactie te beheren.
Da's zo geen goed idee vind ik, aangezien het eigenlijk de client is die het transactie-bheer voor zich moet nemen.

[Alarmnummer]

whoami schreef op vrijdag 08 juli 2005 @ 21:31:
Het probleem bij dat DAO example (zoals ik het nu zo snel zie), is dat die DAO blijkbaar ook de verantwoordelijkheid op zich neemt om de transactie te beheren.

Het voorbeeld heb ik niet bekeken, maar een DAO hoort idd geen transacties te beheren. Dat is onderdeel van de service/manager/businesslogica/applicationlayer.. zo.. nog namen vergeten?

[EfBe]

Alarmnummer schreef op vrijdag 08 juli 2005 @ 17:44:
Blader maar eens wat over DAO (Data Access Object) ontwerp. DAL = een 100% .NET kreet.. De rest van de wereld (Java ) gebruikt altijd DAO. Maar principe komt overeen (denk ik)..

Nee die zijn niet hetzelfde.

DAL is een term uit de n-tier familie van termen, en omvat de complete layer die data-access regelt. een DAO is 1 object, en je kunt bv meerdere DAO's hebben, 1 per entity type bv. (je kunt ook een generieke maken). In wezen is het dus zo dat meerdere DAO's 1 DAL vormen

[whoami]

Alarmnummer schreef op vrijdag 08 juli 2005 @ 21:37:
[...]

Het voorbeeld heb ik niet bekeken, maar een DAO hoort idd geen transacties te beheren. Dat is onderdeel van de service/manager/businesslogica/applicationlayer

En hoe doe jij dat dan concreet ?

[Alarmnummer]

whoami schreef op vrijdag 08 juli 2005 @ 21:39:
[...]

En hoe doe jij dat dan concreet ?

Heel simpel:
voor kleine webapplicaties met niet al te veel logica, maak ik de controllers gewoon transactioneel. Afhandeling van 1 request -> 1 transactie. ALs er iets mislukt dan wordt de transactie gerollbacked (je kunt ook zelf rollbacken). De transactie wordt nog niet meteen afgesloten trouwens, maar de view krijgt nog de kans om lazyloaded data alsnog in te laden (open session in view).

Voor complexere applicaties maak ik de services/managers transactioneel door ze te voorzien van transactionele metadata en dit geheel in spring aan te sluiten.

code:

interface PnlManager{
 
         .....

    @Transactional(readOnly = true, propagation = Propagation.REQUIRED)
    List findAllProjectCategorie();

    @Transactional(readOnly = false, propagation = Propagation.REQUIRED)
    void saveOrUpdate(ProjectCategorie cat);

    @Transactional(readOnly = false, propagation = Propagation.REQUIRED)
    void delete(ProjectCategorie cat);
 
         .....
}

Isolation hoef ik hier niet in te stellen, die staat default meestal goed genoeg.

De PNLmanager maakt gebruik van een hele zwik met dao`s. Via de PNL manager coordineer ik nu de transacties.. super eenvoudig.

[ Voor 7% gewijzigd door Alarmnummer op 08-07-2005 21:48 ]

[Alarmnummer]

EfBe schreef op vrijdag 08 juli 2005 @ 21:39:
[...]

Nee die zijn niet hetzelfde.

DAL is een term uit de n-tier familie van termen, en omvat de complete layer die data-access regelt. een DAO is 1 object, en je kunt bv meerdere DAO's hebben, 1 per entity type bv. (je kunt ook een generieke maken). In wezen is het dus zo dat meerdere DAO's 1 DAL vormen

Goeie uitleg.

[Verwijderd]

très bien, hier kan ik wel even mee verder

[ Voor 3% gewijzigd door Verwijderd op 09-07-2005 14:45 ]

[curry684]

EfBe schreef op vrijdag 08 juli 2005 @ 21:39:
[...]

Nee die zijn niet hetzelfde.

DAL is een term uit de n-tier familie van termen, en omvat de complete layer die data-access regelt. een DAO is 1 object, en je kunt bv meerdere DAO's hebben, 1 per entity type bv. (je kunt ook een generieke maken). In wezen is het dus zo dat meerdere DAO's 1 DAL vormen

Met de betekenis van de afko is het verschil in principe uberhaupt wel duidelijk: Data Access Layer cq. Database Abstraction Layer afhankelijk van wie je het vraagt. Maar in beide betekenissen is het idd een 'layer' van de programmatuur en daarmee een 1..* verzameling van Data Access Objects