OR Mapperns plats i arkitekturen

Ja, min syn på LazyLoad är detsamma.
Ok, du kodar alltså dina objekt för hand? ;)

_OrderRows = new OrderRows(_OrderHeaderId);

Med tanke på detta, du har alltså constructors i dina objekt? Anropar de OR Mappern och fylls med det OR Mappern returnerar, eller?

Dubbel post...

Med tanke på detta, du har alltså constructors i dina objekt?

Det har nästan alla objekt :)
----------------------------------------------------------------

Japp, just för tillfället så kodas objekten för hand.

Min konstrukter så ut ungefär så här:

public OrderRows(long orderHeaderId){
  //-- Create query object
  IQuery query = new Query(Fields.OrderHeaderId, orderHeaderId, SqlOperator.Equal);
  // -- Create dataManager
  IDataManager dataManager = new DataManager();
  //-- Fill this object with data from datasource
  dataManager.Load(this, query);
}

Om jag hade haft en ORMapper som tog emot en typ och skapade ett objekt så hade jag inte kunnat göra så, om jag inte hade velat göra en massa properties matchningar. Det betyder också att jag låter mina object inte bara vara korkade object utan de innehåller den "affärslogik" som just det objektet behöver.

Skulle jag använda mig av SOA istället så hade jag endast använt dumma objekt och lagt ett BusinessLager ovanpå min SOA fasad. Det betyder att min O/R Mapper kan hantera båda sätten :)

- magnus

För min del så har jag fortfarande inte bestämt mig vilken väg jag ska ta. Nu på förmiddagen har jag haft lite tid att börja peta i det så jag har optimerat min databas och nu ska jag ta tag i OR Mappern och se vad jag ska göra med den.
Jag lutar åt dumma objekt och ett BusinessLogicLayer, men i det här fallet så skulle det då innebära att LazyLoadern i Order objektet anropar BusinessLogiken som låter OR Mappern hämta det objekt jag behöver?

Jobbigt att försöka tänka på nya sätt när man har mycket att göra.

Jag lutar åt dumma objekt och ett BusinessLogicLayer, men i det här fallet så skulle det då innebära att LazyLoadern i Order objektet anropar BusinessLogiken som låter OR Mappern hämta det objekt jag behöver?

Nja!! Dina business object bör inte känna till ditt BusinessLogik lager. Och om de är dumma så skall de inte innehålla logik som lazyloading. Du bör så fall istället skapa en Metod i ditt logiklager som kan hämta alla orderRows för en specifik Order. Om du går mot Dumma objekt och mer mot en logiklager så bör dina objekt inte klara av följande: [Fet]Order.Orders[2].Product[0].Name[/Fet] utan så fall skall du skapa olika methoder i ditt logiklager:

LogikLager.GetOrders(customerId)
LogikLager.GetOrderRows(OrderId)
LogikLager.GetProducts(OrderRowId)

Och så låter du ditt FrontEnd jobba mot dessa metoder istället. Om du istället väljer att ha smarta objekt så kan du göra som jag gör, med lazyloading och fylla objekten i construktorn. Du tar "iprincip" bort ditt LogikLager så fall. Eller så behåller du det för att avgränsa din FrontEnd mot ditt businesslager, eller så struntar du i det och låter ditt FrontEnd prata direkt med ditt BusinessLager.

Allt är en avvägning mellan hur flexibelt och avgärnssat du vill ha ditt system jämfört med din utvecklingstid och underhållsarbete.

Vi gjorde ett liten POC (Proof Of Contest) i jobbet där vi skulle ha en liten webbank (skrev om det i en annan tråd) där vi hade typ 6 lager och ett definitionslager som gick på tvärs, där vi blandade det bästa från SOA och OO till en (enligt vår åsikt) en ganska schysst design. Man skulle dock kunnat lösa uppgiften med endast 2 lager och så fall slippa en massa tunna wrapperlager som inte gör något mer än kastar commandot vidare i mellan lagerna, det skulle gå mycket fortare att bygga, men vara betydligt svårare att byta ut någon del, om det skulle behövas.

Det viktiga är att du är nöjd med din lösning, och att det är rätt avvägning mellan design/prestand/utvecklingstid för just dig. Känner du på dig att det kommer att utvecklas mer/byggas om/ändras så satsa på att avgränsa i fler lager, vet du med dig att det inte kommer att ändras så mycket, designa inte ihjäl dig då eftersom du inte får någon nytta av de fördelar som flera lager kommer att ge, endast nackdelarna med längre utvecklingstid och komplexibilitet.

p.s fick du tag i någon hjälp till ditt företag?

- M

Ok, då börjar bitarna falla på plats.
Jag använder Wilson OR Mapper och sen kör jag CodeSmith för att generera all kod. Har färdiga mallar för att generera "dumma" objekt. Får se om jag kan sätta ihop någon smart affärslogik eller om det blir smidigare med smarta objekt.
Anledningen till att jag väger åt dumma objekt är just det där med lager och att det blir lättare att ändra och byta ut delar. Det kommer att byggas till mycket ny funktionalitet framöver vilket kanske innebär ändringar i vissa lager.

p.s fick du tag i någon hjälp till ditt företag?

Ja, jag har sammanställt en lista på folk och företag jag kan kontakta när det kniper. Vad det handlar om är att jag och min kollega har en hel del offerter ute och potentiella kunder på gång och om det blir för många projekt på en gång så kommer jag behöva lägga ut en del kodning. Så det är bäst att vara förberedd. :)

Då kanske du skall kolla på designen som vi gjorde för vår InternetBank: http://www.webforum.nu/showthread.php?s=&threadid=109503&forumid=29

Där har vi som sagt ett BusinessLager ovanpå ett ProcessLager (SOA fasaden). Och så skickar vi endast interface mellan lagerna. Tycker faktiskt den lösningen är rätt snygg, det gör att personen som skall skriva FrontEnden inte bryr sig om att det finns en SOA aritektur nedan utan kan skriva Order.OrderRow[0].Product[3].Name och så omvandla BusinessLagret detta till SOA Anrop på olika methoder. Om du då har olika SOA Fasader att hämta dataifrån, så kapslar du in det snyggt i ditt BusinessLager. Dessutom så låter du ditt ProcessLager endast skicka tillbaka Interface eller Arrayer av interface vilket för att det blir extremt enkelt att omvandla till en WebService om detta kan komma på tal längre fram. Men som sagt 8 olika lager som skall skrivas för att hämta data från en databas till en websida!!!! Fördelan är ju att så fort man byggt lagrerna upp till ProcessLageret så kan ju vilken applikation som helst använda sig av dessa, och på dettavis så kan man återanvända koden i andra projekt, om de nu behöver denna funktionallitet. Bäst är denna design om man vill ha flera olika frontends att köra på, då behöver man ju bara skriva om de 3 överstalagerna, eller kanske till och med endast det översta beroend på hur viktigt separationen mellan projekten är.

Håller just nu på med en StandarKomponent för att sköta remotingen mellan Business.Dispatcher och Process.Receiver där man enkelt kan välja om man vill köra med remoting över nätverket, eller om man väljer att instancerar ett lokalt objekt och där med få prestandavinster. Denna komponent använder sig av Microsoft.Sample.Runtime.Remoting.Security för att kunna Impersonate en användare på clientsida även på serversidan, kan ju vara bra om man har olika rättigheter på olika användare på serversidan. Rätt kul faktiskt...

- M

Lysande, ska läsa igenom det där.

Anledningen till att jag inte har något emot att det blir många lager är att:
1. Det kommer bli WebServices i framtiden
2. Plattformen kommer att användas för både webb och win.
3. Har som sagt mycket funktionalitet att bygga på med framöver och vill inte riskera att det blir strul att ändra och byta ut saker och ting.

Jag bloggar väl om det allteftersom jag får ihop grejorna.