SOA, frågor

Har precis hittat till detta forum och det kanske finns någon som kan ge mig en spark i rätt riktning.

Jag har funderat på SOA och har ett par funderingar, lått oss säga att jag använder mig av Data Access Application Block i Enterprise Library som DAL, sen har jag x antal BO i ett BL som i sin tur har funktioner för att arbeta mot DAL, spara, uppdatera och radera från en databas. Sedan har jag ett Service-lager som arbetar mot BL utifrån en webservice eller ett presentationslager. Det känns inte riktigt korrekt att skicka BO runt mellan lagrena och då har jag tänkt man kan använda sig av Data transfer objects, DTO men jag kan inte riktigt greppa hur det skulle gå till, om mina DTO motsvarar entiteterna i BL fast utan metoder och bara en massa propertys. Låt oss anta att jag har en BO som heter Book, dens uppdateringsmetod, ska den ta in ett BookDTO då? Säg att jag ifrån min webbsida vill uppdatera en bok, då skapar man ett BookDTO, sätter lite propertys och skickar in den i Service-lagret och dess metod UpdateBook(BookDTO book), som i sin tur skickar ner till UpdateBook(BookDTO book) i BL, som i sin tur arbetar med DALet och uppdaterar boken.

Japp helt korrekt. Det du kan göra är att du faktiskt skippar att skapa dina DTO objekt och använder dig av din BO objekt som entiteter, för när de väl lämnar din webservice så innehåller de ingen logik, utan endast data. Det är inte riktigt korrekt men man slipper skapa en massa DTo objekt som iprincip ser likadana ut som BO.

- M

Jag har fått höra många gånger att det är "fult" att ha BO direkt innan presentationslagret så att säga, tex vill man inte arbeta med BO direkt i codebehind till aspx-sidor. Varför har man annars DTO,för att ha enhetlig kommunikation mellan lager? Tack gladh!

Jag har fått höra många gånger att det är "fult" att ha BO direkt innan presentationslagret så att säga, tex vill man inte arbeta med BO direkt i codebehind till aspx-sidor. Varför har man annars DTO,för att ha enhetlig kommunikation mellan lager?

Detta beror oftas på, men visst så skall dina BO finnas i din service och inte i din ASPX kod, men och men, om du skickar ut ett BO från en webservices så är det INTE ett BO objekt som du får ut på andra sidan, utan endast ett DTO objekt som råkar ha precis de properties som ditt BO objekt har. Och här i ligger problemet med att inte använda sig av DTO, så fort du ändrar i ditt BO så ändrar du även i ditt DTO och det är kanske inte något som du önskar, samt att om du istället för att skicka tillbaka BO och istället skickar tillbaka och tar emot DTO till dina services så får du en bra avkoppling mellan interfacet för din services och innehållet vilket gör det enklar för dig att ändra i din BO utan att du ändrar ditt interface, om det nu är det du vill.

- M

Tack gladh, då återstår bara ett problem att lösa, hur jag skapar upp mina olika DTO, har googlat och hittat massa patterns för J2EE, session facade osv, vet du något lämpligt för en .net applikation? Jag vet att patterns är generella men när jag kollat i petshopexemplena blir jag mestadels förvirrad. Jag hittade en bok av Fowler men den blev jag inte klokare av, jag kollade i PDF:en Enterprise Solution Patterns
Using Microsoft .NET men de använder typade datasets vilket jag inte vill använda utan jag vill använda DTO:er som representerar mina BO, en massa get/set utan funktionalitet.

Red. Jag har hittat info om mapper-pattern av Fowler, men något vägrar trilla in i min skalle, mitt BO ska ju inte känna till mina DTO och vice versa, vem ska sköta kommunikationen för att spara ner till databasen,hämta via dalet osv. Om jag som i exemplet ovan skickar in ett DTO till ett BO måste ju BO känna till DTO,vilket inte känns rätt

Det vi gör är att om du har en service så består den av 3 lager.

- ServiceInterface
- Business
- ServiceAgent

- ServiceInterface är din ingång till servicen, kanske en webservice, detta lager känner till din DTO och BO, och mappar sedan mellan dessa 2 objekt.
- Business är det lager som opererar med/på dina BO, alltså här finns inga DTO objekt utan bara BO.
- ServiceAgent har som uppgift att sköta kommunikation till andra services/datakäller som denna service behöver och här mappar man återigen mellan DTO och BO objekten.

Jag kanske skall tillägga att vi inte använder oss av rena BO objekt i som i OO, utan använder mer med Manager klasser som opererar på våra BO (som iprincip är ett DTO). Så vårt business ser ut så här.

business.SaveUser(DTOUser user);

Du kan läsa här hur MS vill att du skall bygga det: http://msdn.microsoft.com/practices/apptype/distapps/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp

- M

Tack för svaret, har redan läst den serien på msdn, men de propagerar bara för typade datasets som jag inte direkt finner njutbara alltid, kommer nog gå att köra med hibernate eller wilsson och ha ett lager som sköter transformeringar från BO till DTO, ett servicelager kanske man kan likna det vid fast inte ett servicelager ut mot andra tjänster