Tja första gången jag skriver i ALT.NET gruppen känns bra har följ gruppen ett tag.
Jo vi skall hoppa in på Silverlight spåret på jobbet och har tidigare jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
Som rubriken säger så undrar jag hur man på bästa sätt konverterar DTO objekten på Silverlight klienten men även också åt andra hållet på WCF servicen till DDD objekt.
Tidigare har vi haft lyxen med WPF som har fullt stöd för reflection som inte Silverlight har kunnat skicka över våra DDD objekt exakt som dom ser ut utan att behöva tänka på att alla properties måste ha Get; Set eller vara publika osv. Nu med silverlight så känns det som att det inte går längre eftersom reflectionbegränsningen gör att vi inte kan använda oss av den metodiken.
Så hur skall vi gå tillväga??
Ha get; set; properties på alla dataparameterar är helt uteslutet.
Jag har några approacher men i varje approach så måste domänmodellen känna till DTO:n vilket är tråkigt men vi kanske inte undkommer det?
Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta den sätta alla medlemsvariabler. Ha en internal metod som tar emot dto:n isf känns alternativ 1 bättre.
Eller finns det någon riktigt bra lösning på detta?
> Tja första gången jag skriver i ALT.NET gruppen känns bra har följ > gruppen ett tag.
> Jo vi skall hoppa in på Silverlight spåret på jobbet och har tidigare > jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> Som rubriken säger så undrar jag hur man på bästa sätt konverterar DTO > objekten på Silverlight klienten men även också åt andra hållet på WCF > servicen till DDD objekt.
> Tidigare har vi haft lyxen med WPF som har fullt stöd för reflection > som inte Silverlight har kunnat skicka över våra DDD objekt exakt som > dom ser ut utan att behöva tänka på att alla properties måste ha Get; > Set eller vara publika osv. Nu med silverlight så känns det som att > det inte går längre eftersom reflectionbegränsningen gör att vi inte > kan använda oss av den metodiken.
> Så hur skall vi gå tillväga??
> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> Jag har några approacher men i varje approach så måste domänmodellen > känna till DTO:n vilket är tråkigt men vi kanske inte undkommer det?
> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > den sätta alla medlemsvariabler. > Ha en internal metod som tar emot dto:n isf känns alternativ 1 bättre.
> Eller finns det någon riktigt bra lösning på detta?
Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta mot DTOer, och i ditt service lager kan du köra med AutoMapper för att underlätta mappning.
Aspen projektet tillsammans med MS kommer att göra precis det, eller den gör det idag men har inte hunnit blogga om det.. här är min senate post:
> Spontant så tror jag att det är AutoMapper som skulle passa bäst men jag > är osäker på om den funkar i silverlight.
> /Andreas
> ________________________
> On 2010-01-21 21:25:25 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
>> Tja första gången jag skriver i ALT.NET gruppen känns bra har följ >> gruppen ett tag.
>> Jo vi skall hoppa in på Silverlight spåret på jobbet och har tidigare >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
>> Som rubriken säger så undrar jag hur man på bästa sätt konverterar DTO >> objekten på Silverlight klienten men även också åt andra hållet på WCF >> servicen till DDD objekt.
>> Tidigare har vi haft lyxen med WPF som har fullt stöd för reflection >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt som >> dom ser ut utan att behöva tänka på att alla properties måste ha Get; >> Set eller vara publika osv. Nu med silverlight så känns det som att >> det inte går längre eftersom reflectionbegränsningen gör att vi inte >> kan använda oss av den metodiken.
>> Så hur skall vi gå tillväga??
>> Ha get; set; properties på alla dataparameterar är helt uteslutet.
>> Jag har några approacher men i varje approach så måste domänmodellen >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer det?
>> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta >> den sätta alla medlemsvariabler. >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 bättre.
>> Eller finns det någon riktigt bra lösning på detta?
> -- > Det här meddelandet skickas till dig eftersom du prenumererar på gruppen > Sweden ALT.NET i Google Groups. > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > sweden-altnet@googlegroups.com. > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > sweden-altnet+unsubscribe@googlegroups.com. > För fler alternativ, besök gruppen på > http://groups.google.com/group/sweden-altnet?hl=sv.
Problemet med att en Automapper inte löser mina program, det jag trycker på ovan är att jag absolut inte vill ha get; set funktionalitet på alla medlemsvariabler. Visa variabler vill jag inte att man ändrar via en property utan skall räknas ut eller sättas via en metod.
Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den propertyn bör det enbart sitta set på för den ska aldrig ändras. Men med automapper så fungerar ju inte det.
Därför söker jag andra lösningar. Jag vill inte heller att all logik skall avgöras av min viewmodel då den enligt mig inte skall ha affärslogik som att räkna ut vad slutsumman blir på antalet fakturarader t.ex. det är funktionalitet jag vill kunna ha i en entitet som viewmodel arbetar mot.
On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote:
> Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta mot > DTOer, och i ditt service lager kan du köra med AutoMapper för att > underlätta mappning.
> Aspen projektet tillsammans med MS kommer att göra precis det, eller den gör > det idag men har inte hunnit blogga om det.. här är min senate post:
> > Spontant så tror jag att det är AutoMapper som skulle passa bäst men jag > > är osäker på om den funkar i silverlight.
> > /Andreas
> > ________________________
> > On 2010-01-21 21:25:25 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> >> Tja första gången jag skriver i ALT.NET gruppen känns bra har följ > >> gruppen ett tag.
> >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har tidigare > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> >> Som rubriken säger så undrar jag hur man på bästa sätt konverterar DTO > >> objekten på Silverlight klienten men även också åt andra hållet på WCF > >> servicen till DDD objekt.
> >> Tidigare har vi haft lyxen med WPF som har fullt stöd för reflection > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt som > >> dom ser ut utan att behöva tänka på att alla properties måste ha Get; > >> Set eller vara publika osv. Nu med silverlight så känns det som att > >> det inte går längre eftersom reflectionbegränsningen gör att vi inte > >> kan använda oss av den metodiken.
> >> Så hur skall vi gå tillväga??
> >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> >> Jag har några approacher men i varje approach så måste domänmodellen > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer det?
> >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > >> den sätta alla medlemsvariabler. > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 bättre.
> >> Eller finns det någon riktigt bra lösning på detta?
> > -- > > Det här meddelandet skickas till dig eftersom du prenumererar på gruppen > > Sweden ALT.NET i Google Groups. > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > > sweden-altnet@googlegroups.com. > > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > > sweden-altnet+unsubscribe@googlegroups.com. > > För fler alternativ, besök gruppen på > >http://groups.google.com/group/sweden-altnet?hl=sv.
> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar via en property utan skall> räknas ut eller sättas via en metod.Det låter som om det är en hybrid mellan DTO:er och domän object du skickar mellan client och server. DTO:er skall inte innehålla nått beteende så renodlade sådana blir bara ett class med en massa auto properties på. Ie helt ok med get;set; > Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men med automapper så fungerar ju inte det.Automapper används bara för att mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast på elegant code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är ett subset av all data som domänobjektet innehåller. Det gör att man ofta måste använda nått form av "repository" för att först ladda domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag brukar försöka lösa det så att när gui vill uppdatera så skickar det ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det är enklare att tänka så :) ) till servicelagret som: 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command + ev. defaults)4. Sparar på något sätt Exempel: På client: wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand ...) På server public class UpdateCustomerStatusHandler: IHandleMessage< UpdateCustomerStatusCommand >{ public Handle(UpdateCustomerStatusCommand command) { var customerToUpdate =repository.Get<Customer>(command.CustomerId); customerToUpdate.ChangeStatus( command.NewStatus); repository.Update(customerToUpdate); }}
> Date: Thu, 21 Jan 2010 13:03:57 -0800 > Subject: Re: Silverlight, DTO, DDD > From: pehrs...@gmail.com > To: sweden-altnet@googlegroups.com
> Problemet med att en Automapper inte löser mina program, det jag > trycker på ovan är att jag absolut inte vill ha get; set > funktionalitet på alla medlemsvariabler. > Visa variabler vill jag inte att man ändrar via en property utan skall > räknas ut eller sättas via en metod.
> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > propertyn bör det enbart sitta set på för den ska aldrig ändras. > Men med automapper så fungerar ju inte det.
> Därför söker jag andra lösningar. Jag vill inte heller att all logik > skall avgöras av min viewmodel då den enligt mig inte skall ha > affärslogik som att räkna ut vad slutsumman blir på antalet > fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > entitet som viewmodel arbetar mot.
> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta mot > > DTOer, och i ditt service lager kan du köra med AutoMapper för att > > underlätta mappning.
> > Aspen projektet tillsammans med MS kommer att göra precis det, eller den gör > > det idag men har inte hunnit blogga om det.. här är min senate post:
> > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har följ > > >> gruppen ett tag.
> > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har tidigare > > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> > >> Som rubriken säger så undrar jag hur man på bästa sätt konverterar DTO > > >> objekten på Silverlight klienten men även också åt andra hållet på WCF > > >> servicen till DDD objekt.
> > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för reflection > > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt som > > >> dom ser ut utan att behöva tänka på att alla properties måste ha Get; > > >> Set eller vara publika osv. Nu med silverlight så känns det som att > > >> det inte går längre eftersom reflectionbegränsningen gör att vi inte > > >> kan använda oss av den metodiken.
> > >> Så hur skall vi gå tillväga??
> > >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> > >> Jag har några approacher men i varje approach så måste domänmodellen > > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer det?
> > >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > > >> den sätta alla medlemsvariabler. > > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 bättre.
> > >> Eller finns det någon riktigt bra lösning på detta?
> > > -- > > > Det här meddelandet skickas till dig eftersom du prenumererar på gruppen > > > Sweden ALT.NET i Google Groups. > > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > > > sweden-altnet@googlegroups.com. > > > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > > > sweden-altnet+unsubscribe@googlegroups.com. > > > För fler alternativ, besök gruppen på > > >http://groups.google.com/group/sweden-altnet?hl=sv.
Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna ut vad totalsumman på min faktura blir när jag lägger till en fakturarad t.ex. Jag vill inte att alla beräkningar skall ligga på serversidan. Totalsumman kommer jag inte att skicka över sedan eftersom det är något som räknas ut, men jag vill att användaren skall kunna se totalsumman direkt när raden är tillagd utan ett serviceanrop.
On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote:
> > trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar via en property utan skall> räknas ut eller sättas via en metod.Det låter som om det är en hybrid mellan DTO:er och domän object du skickar mellan client och server. DTO:er skall inte innehålla nått beteende så renodlade sådana blir bara ett class med en massa auto properties på. Ie helt ok med get;set; > > Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men med automapper så fungerar ju inte det.Automapper används bara för att mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast på elegant code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är ett subset av all data som domänobjektet innehåller. Det gör att man ofta måste använda nått form av "repository" för att först ladda domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag brukar försöka lösa det så att när gui vill uppdatera så skickar det ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det är enklare att tänka så :) ) till servicelagret som: > 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command + ev. defaults)4. Sparar på något sätt > Exempel: > På client: > wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand ...) > På server > public class UpdateCustomerStatusHandler: IHandleMessage< UpdateCustomerStatusCommand >{ > public Handle(UpdateCustomerStatusCommand command) { > var customerToUpdate =repository.Get<Customer>(command.CustomerId); > customerToUpdate.ChangeStatus( command.NewStatus); > repository.Update(customerToUpdate); }}
> > Problemet med att en Automapper inte löser mina program, det jag > > trycker på ovan är att jag absolut inte vill ha get; set > > funktionalitet på alla medlemsvariabler. > > Visa variabler vill jag inte att man ändrar via en property utan skall > > räknas ut eller sättas via en metod.
> > Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > > propertyn bör det enbart sitta set på för den ska aldrig ändras. > > Men med automapper så fungerar ju inte det.
> > Därför söker jag andra lösningar. Jag vill inte heller att all logik > > skall avgöras av min viewmodel då den enligt mig inte skall ha > > affärslogik som att räkna ut vad slutsumman blir på antalet > > fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > > entitet som viewmodel arbetar mot.
> > On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta mot > > > DTOer, och i ditt service lager kan du köra med AutoMapper för att > > > underlätta mappning.
> > > Aspen projektet tillsammans med MS kommer att göra precis det, eller den gör > > > det idag men har inte hunnit blogga om det.. här är min senate post:
> > > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har följ > > > >> gruppen ett tag.
> > > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har tidigare > > > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> > > >> Som rubriken säger så undrar jag hur man på bästa sätt konverterar DTO > > > >> objekten på Silverlight klienten men även också åt andra hållet på WCF > > > >> servicen till DDD objekt.
> > > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för reflection > > > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt som > > > >> dom ser ut utan att behöva tänka på att alla properties måste ha Get; > > > >> Set eller vara publika osv. Nu med silverlight så känns det som att > > > >> det inte går längre eftersom reflectionbegränsningen gör att vi inte > > > >> kan använda oss av den metodiken.
> > > >> Så hur skall vi gå tillväga??
> > > >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> > > >> Jag har några approacher men i varje approach så måste domänmodellen > > > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer det?
> > > >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > > > >> den sätta alla medlemsvariabler. > > > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 bättre.
> > > >> Eller finns det någon riktigt bra lösning på detta?
> > > > -- > > > > Det här meddelandet skickas till dig eftersom du prenumererar på gruppen > > > > Sweden ALT.NET i Google Groups. > > > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > > > > sweden-altnet@googlegroups.com. > > > > Om du vill sluta prenumerera på den här gruppen skickar du e-post till > > > > sweden-altnet+unsubscribe@googlegroups.com. > > > > För fler alternativ, besök gruppen på > > > >http://groups.google.com/group/sweden-altnet?hl=sv.
> Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > ut vad totalsumman på min faktura blir när jag lägger till en > fakturarad t.ex. > Jag vill inte att alla beräkningar skall ligga på serversidan. > Totalsumman kommer jag inte att skicka över sedan eftersom det är > något som räknas ut, men jag vill att användaren skall kunna se > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar >>> via en property utan skall> räknas ut eller sättas via en metod.Det >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar >>> mellan client och server. DTO:er skall inte innehålla nått beteende så >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie >>> helt ok med get;set; >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men >>> med automapper så fungerar ju inte det.Automapper används bara för att >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast >>> på elegant >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
>> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är >> ett subset av all data som domänobjektet innehåller. Det gör att man >> ofta måste använda nått form av "repository" för att först ladda >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag >> brukar försöka lösa det så att när gui vill uppdatera så skickar det >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det >> är enklare att tänka så :) ) till servicelagret som: >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command >> + ev. defaults)4. Sparar på något sätt >> Exempel: >> På client: >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand >> ...) >> På server >> public class UpdateCustomerStatusHandler: IHandleMessage< >> UpdateCustomerStatusCommand >{ >> public Handle(UpdateCustomerStatusCommand command) { >> var customerToUpdate >> =repository.Get<Customer>(command.CustomerId); >> customerToUpdate.ChangeStatus( command.NewStatus); >> repository.Update(customerToUpdate); }}
>>> Date: Thu, 21 Jan 2010 13:03:57 -0800 >>> Subject: Re: Silverlight, DTO, DDD >>> From: pehrs...@gmail.com >>> To: sweden-altnet@googlegroups.com
>>> Problemet med att en Automapper inte löser mina program, det jag >>> trycker på ovan är att jag absolut inte vill ha get; set >>> funktionalitet på alla medlemsvariabler. >>> Visa variabler vill jag inte att man ändrar via en property utan skall >>> räknas ut eller sättas via en metod.
>>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. >>> Men med automapper så fungerar ju inte det.
>>> Därför söker jag andra lösningar. Jag vill inte heller att all logik >>> skall avgöras av min viewmodel då den enligt mig inte skall ha >>> affärslogik som att räkna ut vad slutsumman blir på antalet >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en >>> entitet som viewmodel arbetar mot.
>>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta >>> mot >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att >>> > underlätta mappning.
>>> > Aspen projektet tillsammans med MS kommer att göra precis det, eller >>> den gör >>> > det idag men har inte hunnit blogga om det.. här är min senate post:
>>> > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har >>> följ >>> > >> gruppen ett tag.
>>> > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har >>> tidigare >>> > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
>>> > >> Som rubriken säger så undrar jag hur man på bästa sätt >>> konverterar DTO >>> > >> objekten på Silverlight klienten men även också åt andra hållet >>> på WCF >>> > >> servicen till DDD objekt.
>>> > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för >>> reflection >>> > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt >>> som >>> > >> dom ser ut utan att behöva tänka på att alla properties måste ha >>> Get; >>> > >> Set eller vara publika osv. Nu med silverlight så känns det som att >>> > >> det inte går längre eftersom reflectionbegränsningen gör att vi >>> inte >>> > >> kan använda oss av den metodiken.
>>> > >> Så hur skall vi gå tillväga??
>>> > >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
>>> > >> Jag har några approacher men i varje approach så måste >>> domänmodellen >>> > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer >>> det?
>>> > >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta >>> > >> den sätta alla medlemsvariabler. >>> > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 >>> bättre.
>>> > >> Eller finns det någon riktigt bra lösning på detta?
>>> > > -- >>> > > Det här meddelandet skickas till dig eftersom du prenumererar på >>> gruppen >>> > > Sweden ALT.NET i Google Groups. >>> > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till >>> > > sweden-altnet@googlegroups.com. >>> > > Om du vill sluta prenumerera på den här gruppen skickar du e-post >>> till >>> > > sweden-altnet+unsubscribe@googlegroups.com. >>> > > För fler alternativ, besök gruppen på >>> > >http://groups.google.com/group/sweden-altnet?hl=sv.
> Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> var orderTotal = priceCalculator.CalculateTotalFor(order);
> Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> /Andreas
> ________________________
> On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > ut vad totalsumman på min faktura blir när jag lägger till en > > fakturarad t.ex. > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > något som räknas ut, men jag vill att användaren skall kunna se > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie > >>> helt ok med get;set; > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men > >>> med automapper så fungerar ju inte det.Automapper används bara för att > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > >>> på elegant > >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är > >> ett subset av all data som domänobjektet innehåller. Det gör att man > >> ofta måste använda nått form av "repository" för att först ladda > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > >> är enklare att tänka så :) ) till servicelagret som: > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > >> + ev. defaults)4. Sparar på något sätt > >> Exempel: > >> På client: > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > >> ...) > >> På server > >> public class UpdateCustomerStatusHandler: IHandleMessage< > >> UpdateCustomerStatusCommand >{ > >> public Handle(UpdateCustomerStatusCommand command) { > >> var customerToUpdate > >> =repository.Get<Customer>(command.CustomerId); > >> customerToUpdate.ChangeStatus( command.NewStatus); > >> repository.Update(customerToUpdate); }}
> >>> Problemet med att en Automapper inte löser mina program, det jag > >>> trycker på ovan är att jag absolut inte vill ha get; set > >>> funktionalitet på alla medlemsvariabler. > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > >>> räknas ut eller sättas via en metod.
> >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > >>> Men med automapper så fungerar ju inte det.
> >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > >>> entitet som viewmodel arbetar mot.
> >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > >>> mot > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att > >>> > underlätta mappning.
> >>> > Aspen projektet tillsammans med MS kommer att göra precis det, eller > >>> den gör > >>> > det idag men har inte hunnit blogga om det.. här är min senate post:
> >>> > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har > >>> följ > >>> > >> gruppen ett tag.
> >>> > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har > >>> tidigare > >>> > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> >>> > >> Som rubriken säger så undrar jag hur man på bästa sätt > >>> konverterar DTO > >>> > >> objekten på Silverlight klienten men även också åt andra hållet > >>> på WCF > >>> > >> servicen till DDD objekt.
> >>> > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för > >>> reflection > >>> > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt > >>> som > >>> > >> dom ser ut utan att behöva tänka på att alla properties måste ha > >>> Get; > >>> > >> Set eller vara publika osv. Nu med silverlight så känns det som att > >>> > >> det inte går längre eftersom reflectionbegränsningen gör att vi > >>> inte > >>> > >> kan använda oss av den metodiken.
> >>> > >> Så hur skall vi gå tillväga??
> >>> > >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> >>> > >> Jag har några approacher men i varje approach så måste > >>> domänmodellen > >>> > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer > >>> det?
> >>> > >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > >>> > >> den sätta alla medlemsvariabler. > >>> > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 > >>> bättre.
> >>> > >> Eller finns det någon riktigt bra lösning på detta?
> >>> > > -- > >>> > > Det här meddelandet skickas till dig eftersom du prenumererar på > >>> gruppen > >>> > > Sweden ALT.NET i Google Groups. > >>> > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > >>> > > sweden-altnet@googlegroups.com. > >>> > > Om du vill sluta prenumerera på den här gruppen skickar du e-post > >>> till > >>> > > sweden-altnet+unsubscribe@googlegroups.com. > >>> > > För fler alternativ, besök gruppen på > >>> > >http://groups.google.com/group/sweden-altnet?hl=sv.
btw du har rätt om att beräkningslogiken skall kunna ligga på andra ställen men jag vill att den skall kunna ligga i mitt objekt som jag arbetar med. För att förenkla och minska behovet av att skriva antalet kodrader.
On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote:
> Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> var orderTotal = priceCalculator.CalculateTotalFor(order);
> Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> /Andreas
> ________________________
> On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > ut vad totalsumman på min faktura blir när jag lägger till en > > fakturarad t.ex. > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > något som räknas ut, men jag vill att användaren skall kunna se > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie > >>> helt ok med get;set; > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men > >>> med automapper så fungerar ju inte det.Automapper används bara för att > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > >>> på elegant > >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är > >> ett subset av all data som domänobjektet innehåller. Det gör att man > >> ofta måste använda nått form av "repository" för att först ladda > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > >> är enklare att tänka så :) ) till servicelagret som: > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > >> + ev. defaults)4. Sparar på något sätt > >> Exempel: > >> På client: > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > >> ...) > >> På server > >> public class UpdateCustomerStatusHandler: IHandleMessage< > >> UpdateCustomerStatusCommand >{ > >> public Handle(UpdateCustomerStatusCommand command) { > >> var customerToUpdate > >> =repository.Get<Customer>(command.CustomerId); > >> customerToUpdate.ChangeStatus( command.NewStatus); > >> repository.Update(customerToUpdate); }}
> >>> Problemet med att en Automapper inte löser mina program, det jag > >>> trycker på ovan är att jag absolut inte vill ha get; set > >>> funktionalitet på alla medlemsvariabler. > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > >>> räknas ut eller sättas via en metod.
> >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > >>> Men med automapper så fungerar ju inte det.
> >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > >>> entitet som viewmodel arbetar mot.
> >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > >>> mot > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att > >>> > underlätta mappning.
> >>> > Aspen projektet tillsammans med MS kommer att göra precis det, eller > >>> den gör > >>> > det idag men har inte hunnit blogga om det.. här är min senate post:
> >>> > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har > >>> följ > >>> > >> gruppen ett tag.
> >>> > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har > >>> tidigare > >>> > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> >>> > >> Som rubriken säger så undrar jag hur man på bästa sätt > >>> konverterar DTO > >>> > >> objekten på Silverlight klienten men även också åt andra hållet > >>> på WCF > >>> > >> servicen till DDD objekt.
> >>> > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för > >>> reflection > >>> > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt > >>> som > >>> > >> dom ser ut utan att behöva tänka på att alla properties måste ha > >>> Get; > >>> > >> Set eller vara publika osv. Nu med silverlight så känns det som att > >>> > >> det inte går längre eftersom reflectionbegränsningen gör att vi > >>> inte > >>> > >> kan använda oss av den metodiken.
> >>> > >> Så hur skall vi gå tillväga??
> >>> > >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> >>> > >> Jag har några approacher men i varje approach så måste > >>> domänmodellen > >>> > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer > >>> det?
> >>> > >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > >>> > >> den sätta alla medlemsvariabler. > >>> > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 > >>> bättre.
> >>> > >> Eller finns det någon riktigt bra lösning på detta?
> >>> > > -- > >>> > > Det här meddelandet skickas till dig eftersom du prenumererar på > >>> gruppen > >>> > > Sweden ALT.NET i Google Groups. > >>> > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > >>> > > sweden-altnet@googlegroups.com. > >>> > > Om du vill sluta prenumerera på den här gruppen skickar du e-post > >>> till > >>> > > sweden-altnet+unsubscribe@googlegroups.com. > >>> > > För fler alternativ, besök gruppen på > >>> > >http://groups.google.com/group/sweden-altnet?hl=sv.
Det var inte min mening att framstå som anti OO. Jag syftade på att "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder sig av termen Domain Services för att beskriva dessa "services" som kan användas för att utföra denna typ av "koordinerade logik". Anledningen är att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in repositories etc till din calculate metod på order objektet. Men det blir fort stökigt! Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er som kommer från WCF? Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa en ViewModel som du binder UI:t mot. På denna model kan du lägga en public decimal OrderTotal get return model.OrderLines.Sum(l=>l.Price); I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för att fylla denna modell med data.
> Date: Fri, 22 Jan 2010 01:34:33 -0800 > Subject: Re: Silverlight, DTO, DDD > From: pehrs...@gmail.com > To: sweden-altnet@googlegroups.com
> btw du har rätt om att beräkningslogiken skall kunna ligga på andra > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > arbetar med. > För att förenkla och minska behovet av att skriva antalet kodrader.
> On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> > /Andreas
> > ________________________
> > On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > fakturarad t.ex. > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > något som räknas ut, men jag vill att användaren skall kunna se > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie > > >>> helt ok med get;set; > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men > > >>> med automapper så fungerar ju inte det.Automapper används bara för att > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > > >>> på elegant > > >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är > > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > >> ofta måste använda nått form av "repository" för att först ladda > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > > >> är enklare att tänka så :) ) till servicelagret som: > > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > > >> + ev. defaults)4. Sparar på något sätt > > >> Exempel: > > >> På client: > > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > > >> ...) > > >> På server > > >> public class UpdateCustomerStatusHandler: IHandleMessage< > > >> UpdateCustomerStatusCommand >{ > > >> public Handle(UpdateCustomerStatusCommand command) { > > >> var customerToUpdate > > >> =repository.Get<Customer>(command.CustomerId); > > >> customerToUpdate.ChangeStatus( command.NewStatus); > > >> repository.Update(customerToUpdate); }}
> > >>> Problemet med att en Automapper inte löser mina program, det jag > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > >>> funktionalitet på alla medlemsvariabler. > > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > > >>> räknas ut eller sättas via en metod.
> > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > >>> Men med automapper så fungerar ju inte det.
> > >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik > > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > > >>> entitet som viewmodel arbetar mot.
> > >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > > >>> mot > > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att > > >>> > underlätta mappning.
> > >>> > Aspen projektet tillsammans med MS kommer att göra precis det, eller > > >>> den gör > > >>> > det idag men har inte hunnit blogga om det.. här är min senate post:
> > >>> > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har > > >>> följ > > >>> > >> gruppen ett tag.
> > >>> > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har > > >>> tidigare > > >>> > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> > >>> > >> Som rubriken säger så undrar jag hur man på bästa sätt > > >>> konverterar DTO > > >>> > >> objekten på Silverlight klienten men även också åt andra hållet > > >>> på WCF > > >>> > >> servicen till DDD objekt.
> > >>> > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för > > >>> reflection > > >>> > >> som inte Silverlight har kunnat skicka över våra DDD objekt exakt > > >>> som > > >>> > >> dom ser ut utan att behöva tänka på att alla properties måste ha > > >>> Get; > > >>> > >> Set eller vara publika osv. Nu med silverlight så känns det som att > > >>> > >> det inte går längre eftersom reflectionbegränsningen gör att vi > > >>> inte > > >>> > >> kan använda oss av den metodiken.
> > >>> > >> Så hur skall vi gå tillväga??
> > >>> > >> Ha get; set; properties på alla dataparameterar är helt uteslutet.
> > >>> > >> Jag har några approacher men i varje approach så måste > > >>> domänmodellen > > >>> > >> känna till DTO:n vilket är tråkigt men vi kanske inte undkommer > > >>> det?
> > >>> > >> Man skulle visserligen kunna skicka in dto:n i konstruktorn och låta > > >>> > >> den sätta alla medlemsvariabler. > > >>> > >> Ha en internal metod som tar emot dto:n isf känns alternativ 1 > > >>> bättre.
> > >>> > >> Eller finns det någon riktigt bra lösning på detta?
> > >>> > > -- > > >>> > > Det här meddelandet skickas till dig eftersom du prenumererar på > > >>> gruppen > > >>> > > Sweden ALT.NET i Google Groups. > > >>> > > Om du vill göra ett inlägg i den här gruppen skickar du e-post till > > >>> > > sweden-altnet@googlegroups.com. > > >>> > > Om du vill sluta prenumerera på den här gruppen skickar du e-post > > >>> till > > >>> > > sweden-altnet+unsubscribe@googlegroups.com. > > >>> > > För fler alternativ, besök gruppen på > > >>> > >http://groups.google.com/group/sweden-altnet?hl=sv.
> -- > Det här meddelandet skickas till dig eftersom du prenumererar på gruppen Sweden ALT.NET i Google Groups. > Om du vill göra ett inlägg i den här gruppen skickar du e-post till sweden-altnet@googlegroups.com. > Om du vill sluta prenumerera
Din Service är ett Service lager, ett fönster in till din business logik. Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska inte låta dina domain entiteter bära på datakontrakts information. Skicka den data klienten behöver (Många anser att REST-Service är bäst för RIA, jag säger "det beror på"). På klienten har du en ViewModel. En modell skapad för att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas sa, ska du beräkna pris på klienten utan att du behöver göra server anrop, lägg då den logiken i ViewModel.. ska inte ligga på det objekt du skickar över nätet.. det är fortfarande bara data/message som du skickar inte ett "Object".
Den typ av business logik som ska finnas på klient har enbart med att få upp svarstider på UI.. och skapa en bra användarupplevelse, all annan logik ska placeras på servern.
Viss logik kommer att ligga både på server och klient. Denna logic ska gärna skrivas med samma språk för att underhåll ska bli så enkelt som möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt om). Så då blir det lättare att dela business logik på båda ställen i en enda komponent. Idag så får du ha det på två, eller köra med WCF RIA Services.
Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och vissa saker som du kanske vill göra eller ska göra, blir onödigt komplex.. så väl den modell som passar dig och ditt business case bäst.
Mvh Fredrik Normén
From: Andreas Öhlund Sent: Friday, January 22, 2010 11:08 AM To: sweden-altnet@googlegroups.com Subject: RE: Silverlight, DTO, DDD
Det var inte min mening att framstå som anti OO. Jag syftade på att "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder sig av termen Domain Services för att beskriva dessa "services" som kan användas för att utföra denna typ av "koordinerade logik". Anledningen är att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in repositories etc till din calculate metod på order objektet. Men det blir fort stökigt!
Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er som kommer från WCF?
Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa en ViewModel som du binder UI:t mot. På denna model kan du lägga en
public decimal OrderTotal get return model.OrderLines.Sum(l=>l.Price);
I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för att fylla denna modell med data.
> Date: Fri, 22 Jan 2010 01:34:33 -0800 > Subject: Re: Silverlight, DTO, DDD > From: pehrs...@gmail.com > To: sweden-altnet@googlegroups.com
> btw du har rätt om att beräkningslogiken skall kunna ligga på andra > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > arbetar med. > För att förenkla och minska behovet av att skriva antalet kodrader.
> On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> > /Andreas
> > ________________________
> > On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > fakturarad t.ex. > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > något som räknas ut, men jag vill att användaren skall kunna se > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie > > >>> helt ok med get;set; > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men > > >>> med automapper så fungerar ju inte det.Automapper används bara för att > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > > >>> på elegant > > >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är > > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > >> ofta måste använda nått form av "repository" för att först ladda > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > > >> är enklare att tänka så :) ) till servicelagret som: > > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > > >> + ev. defaults)4. Sparar på något sätt > > >> Exempel: > > >> På client: > > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > > >> ...) > > >> På server > > >> public class UpdateCustomerStatusHandler: IHandleMessage< > > >> UpdateCustomerStatusCommand >{ > > >> public Handle(UpdateCustomerStatusCommand command) { > > >> var customerToUpdate > > >> =repository.Get<Customer>(command.CustomerId); > > >> customerToUpdate.ChangeStatus( command.NewStatus); > > >> repository.Update(customerToUpdate); }}
> > >>> Problemet med att en Automapper inte löser mina program, det jag > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > >>> funktionalitet på alla medlemsvariabler. > > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > > >>> räknas ut eller sättas via en metod.
> > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > >>> Men med automapper så fungerar ju inte det.
> > >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik > > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > > >>> entitet som viewmodel arbetar mot.
> > >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > > >>> mot > > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att > > >>> > underlätta mappning.
> > >>> > Aspen projektet tillsammans med MS kommer att göra precis det, eller > > >>> den gör > > >>> > det idag men har inte hunnit blogga om det.. här är min senate post:
> > >>> > >> Tja första gången jag skriver i ALT.NET gruppen känns bra har > > >>> följ > > >>> > >> gruppen ett tag.
> > >>> > >> Jo vi skall hoppa in på Silverlight spåret på jobbet och har > > >>> tidigare > > >>> > >> jobbat mer med WPF&ClickOnce&WCF men nu blir det silverlight.
> > >>> > >> Som rubriken säger så undrar jag hur man på bästa sätt > > >>> konverterar DTO > > >>> > >> objekten på Silverlight klienten men även också åt andra hållet > > >>> på WCF > > >>> > >> servicen till DDD objekt.
> > >>> > >> Tidigare har vi haft lyxen med WPF som har fullt stöd för > > >>> reflection > > >>> > >> som inte Silverlight har kunnat skicka över våra DDD
Det vi har här är explicit tier bounderies. Man mår bra av att ha specifika modeller för varje tier. Kommunikationen där imellan blir kan man sköta på många olika sätt, DTO'er har vi nämnt, Fredrik var inne på REST. Men gemensamt för allihopa är att kommunkationsmodellen är optimerad för att flytta data över två olika tiers, medans modellerna i SL appen / backend är optimerade för att lösa business cases. Två olika avändningsområden och således två helt olika förhållningssätt.
Businessobjekten mår ju oftast bra av, som nämnts, att vara objekt-orienterade. DTO'er mår sällan bra av OO där är försöker man ju istället arbeta resurs-orienterat (REST) eller Meddelande-orienterat (SOA).
I ljuset av de funderingarna så blir translator-lager oftast nödvändiga, automapper gör en massa gratis där men det finns ju möjlighet att skapa egna translator lager som är speficika för just dina use-cases.
Det är ju också så att meddelande-orienterade lösningar (som man nog måste säga att en SL / WCF lösning är) skall ha WCF gränssnitt som är väldigt specifika för uppgiften. Det innebär ju bland annat att cancel order inte behöver hela ordern med status cancel utan bara id't för den order som backend skall cancellera. Det kan också innebära att GetProductList inte returnerar en mängd med fulla aggregat rötter för Product utan bara det som behövs för att lista produkter (namn, id kanske).
En förlängning av de här ideérna som man kan använda sig av är Udi's funderingar runt Command Query separation på service-nivå. Vilket kort betyder att för Query delen (presentation) så skapar man explicita modeller för varje rapportering man vill göra och binder direkt till dem. "Domänmodellen" används i princip bara för "Command" delen när affärslogik skall utföras, och då oftast på backend.
Oavsett vilken "skola" man hänger på så är de grundläggande principerna för distribuerade lösningar de samma, domainmodels på insidan, kommunikations modeller på utsidan.
Håller fullständigt med Patrik! ( även om jag inte skulle likställa Meddelande-orienterat med SOA, vi får ta det över en öl nån gång :) Tänkte bara tillägga att CQRS ala Udi Dahan finns mycket bra beskrivet här:(varmt rekommenderad läsning) http://www.udidahan.com/2009/12/09/clarified-cqrs/
Date: Fri, 22 Jan 2010 13:09:18 +0100 Subject: Re: Silverlight, DTO, DDD From: patrik.lowend...@gmail.com To: sweden-altnet@googlegroups.com
Det vi har här är explicit tier bounderies. Man mår bra av att ha specifika modeller för varje tier. Kommunikationen där imellan blir kan man sköta på många olika sätt, DTO'er har vi nämnt, Fredrik var inne på REST. Men gemensamt för allihopa är att kommunkationsmodellen är optimerad för att flytta data över två olika tiers, medans modellerna i SL appen / backend är optimerade för att lösa business cases. Två olika avändningsområden och således två helt olika förhållningssätt.
Businessobjekten mår ju oftast bra av, som nämnts, att vara objekt-orienterade. DTO'er mår sällan bra av OO där är försöker man ju istället arbeta resurs-orienterat (REST) eller Meddelande-orienterat (SOA).
I ljuset av de funderingarna så blir translator-lager oftast nödvändiga, automapper gör en massa gratis där men det finns ju möjlighet att skapa egna translator lager som är speficika för just dina use-cases.
Det är ju också så att meddelande-orienterade lösningar (som man nog måste säga att en SL / WCF lösning är) skall ha WCF gränssnitt som är väldigt specifika för uppgiften. Det innebär ju bland annat att cancel order inte behöver hela ordern med status cancel utan bara id't för den order som backend skall cancellera. Det kan också innebära att GetProductList inte returnerar en mängd med fulla aggregat rötter för Product utan bara det som behövs för att lista produkter (namn, id kanske).
En förlängning av de här ideérna som man kan använda sig av är Udi's funderingar runt Command Query separation på service-nivå. Vilket kort betyder att för Query delen (presentation) så skapar man explicita modeller för varje rapportering man vill göra och binder direkt till dem. "Domänmodellen" används i princip bara för "Command" delen när affärslogik skall utföras, och då oftast på backend.
Oavsett vilken "skola" man hänger på så är de grundläggande principerna för distribuerade lösningar de samma, domainmodels på insidan, kommunikations modeller på utsidan.
-- Patrik Löwendahl
--
Det här meddelandet skickas till dig eftersom du prenumererar på gruppen Sweden ALT.NET i Google Groups.
Om du vill göra ett inlägg i den här gruppen skickar du e-post till sweden-altnet@googlegroups.com.
Om du vill sluta prenumerera på den här gruppen skickar du e-post till sweden-altnet+unsubscribe@googlegroups.com.
Jag kan egentligen på tok för lite både om Silverlight och problematiken ni diskuterar för att lägga mig i, men...
Kan man inte likställa kommunikationen i WCF med den mot en databas? Dvs, kan man inte ha ett Repository på klienten som arbetar mot WCF på samma sätt som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive BL istället för dumma DTO:er. Och kanske även bygga en identity map på klientsidan som garanterar att endast en instans finns av varje entitet.
----- Original Message ----- From: fnor...@hotmail.com To: sweden-altnet@googlegroups.com Sent: Friday, January 22, 2010 11:29 AM Subject: Re: Silverlight, DTO, DDD
Note: Min svenska suger fett, så ni bara vet...
Det heter Model View ViewModel :P
DTOer är tillför att begränsa data och för att inte exponera business object över nätet. Läs gärna om DTO här:
Din Service är ett Service lager, ett fönster in till din business logik. Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska inte låta dina domain entiteter bära på datakontrakts information. Skicka den data klienten behöver (Många anser att REST-Service är bäst för RIA, jag säger "det beror på"). På klienten har du en ViewModel. En modell skapad för att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas sa, ska du beräkna pris på klienten utan att du behöver göra server anrop, lägg då den logiken i ViewModel.. ska inte ligga på det objekt du skickar över nätet.. det är fortfarande bara data/message som du skickar inte ett "Object".
Den typ av business logik som ska finnas på klient har enbart med att få upp svarstider på UI.. och skapa en bra användarupplevelse, all annan logik ska placeras på servern.
Viss logik kommer att ligga både på server och klient. Denna logic ska gärna skrivas med samma språk för att underhåll ska bli så enkelt som möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt om). Så då blir det lättare att dela business logik på båda ställen i en enda komponent. Idag så får du ha det på två, eller köra med WCF RIA Services.
Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och vissa saker som du kanske vill göra eller ska göra, blir onödigt komplex.. så väl den modell som passar dig och ditt business case bäst.
Mvh Fredrik Normén
From: Andreas Öhlund Sent: Friday, January 22, 2010 11:08 AM To: sweden-altnet@googlegroups.com Subject: RE: Silverlight, DTO, DDD
Det var inte min mening att framstå som anti OO. Jag syftade på att "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder sig av termen Domain Services för att beskriva dessa "services" som kan användas för att utföra denna typ av "koordinerade logik". Anledningen är att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in repositories etc till din calculate metod på order objektet. Men det blir fort stökigt!
Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er som kommer från WCF?
Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa en ViewModel som du binder UI:t mot. På denna model kan du lägga en
public decimal OrderTotal get return model.OrderLines.Sum(l=>l.Price);
I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för att fylla denna modell med data.
> Date: Fri, 22 Jan 2010 01:34:33 -0800 > Subject: Re: Silverlight, DTO, DDD > From: pehrs...@gmail.com > To: sweden-altnet@googlegroups.com
> btw du har rätt om att beräkningslogiken skall kunna ligga på andra > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > arbetar med. > För att förenkla och minska behovet av att skriva antalet kodrader.
> On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> > /Andreas
> > ________________________
> > On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > fakturarad t.ex. > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > något som räknas ut, men jag vill att användaren skall kunna se > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie > > >>> helt ok med get;set; > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men > > >>> med automapper så fungerar ju inte det.Automapper används bara för att > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > > >>> på elegant > > >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är > > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > >> ofta måste använda nått form av "repository" för att först ladda > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > > >> är enklare att tänka så :) ) till servicelagret som: > > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > > >> + ev. defaults)4. Sparar på något sätt > > >> Exempel: > > >> På client: > > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > > >> ...) > > >> På server > > >> public class UpdateCustomerStatusHandler: IHandleMessage< > > >> UpdateCustomerStatusCommand >{ > > >> public Handle(UpdateCustomerStatusCommand command) { > > >> var customerToUpdate > > >> =repository.Get<Customer>(command.CustomerId); > > >> customerToUpdate.ChangeStatus( command.NewStatus); > > >> repository.Update(customerToUpdate); }}
> > >>> Problemet med att en Automapper inte löser mina program, det jag > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > >>> funktionalitet på alla medlemsvariabler. > > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > > >>> räknas ut eller sättas via en metod.
> > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > >>> Men med automapper så fungerar ju inte det.
> > >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik > > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > > >>> entitet som viewmodel arbetar mot.
> > >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > > >>> mot > > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att > > >>> > underlätta mappning.
> > >>> > Aspen projektet tillsammans med MS kommer att göra precis det, eller > > >>> den gör > > >>> > det idag men har inte hunnit blogga om det.. här är min senate post:
Repositoryt bryr ju sig egentligen inte om vad "storage" är för något utan är bara intresserat av att få ut BE objekt från någon annastans. Oftast brukar det här inte vara just en "Repository" dock utan mer en "proxy" som använder en translator på insidan.
> Jag kan egentligen på tok för lite både om Silverlight och problematiken > ni diskuterar för att lägga mig i, men...
> Kan man inte likställa kommunikationen i WCF med den mot en databas? Dvs, > kan man inte ha ett Repository på klienten som arbetar mot WCF på samma sätt > som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive BL > istället för dumma DTO:er. Och kanske även bygga en identity map på > klientsidan som garanterar att endast en instans finns av varje entitet.
> /T
> ----- Original Message ----- > *From:* fnor...@hotmail.com > *To:* sweden-altnet@googlegroups.com > *Sent:* Friday, January 22, 2010 11:29 AM > *Subject:* Re: Silverlight, DTO, DDD
> Note: Min svenska suger fett, så ni bara vet...
> Det heter Model View ViewModel :P
> DTOer är tillför att begränsa data och för att inte exponera business > object över nätet. Läs gärna om DTO här:
> Din Service är ett Service lager, ett fönster in till din business logik. > Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska inte > låta dina domain entiteter bära på datakontrakts information. Skicka den > data klienten behöver (Många anser att REST-Service är bäst för RIA, jag > säger "det beror på"). På klienten har du en ViewModel. En modell skapad för > att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas sa, > ska du beräkna pris på klienten utan att du behöver göra server anrop, lägg > då den logiken i ViewModel.. ska inte ligga på det objekt du skickar över > nätet.. det är fortfarande bara data/message som du skickar inte ett > "Object".
> Den typ av business logik som ska finnas på klient har enbart med att få > upp svarstider på UI.. och skapa en bra användarupplevelse, all annan logik > ska placeras på servern.
> Viss logik kommer att ligga både på server och klient. Denna logic ska > gärna skrivas med samma språk för att underhåll ska bli så enkelt som > möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt om). Så > då blir det lättare att dela business logik på båda ställen i en enda > komponent. Idag så får du ha det på två, eller köra med WCF RIA Services.
> Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och > vissa saker som du kanske vill göra eller ska göra, blir onödigt komplex.. > så väl den modell som passar dig och ditt business case bäst.
> Mvh Fredrik Normén
> *From:* Andreas Öhlund <andreas_ohl...@hotmail.com> > *Sent:* Friday, January 22, 2010 11:08 AM > *To:* sweden-altnet@googlegroups.com > *Subject:* RE: Silverlight, DTO, DDD
> Det var inte min mening att framstå som anti OO. Jag syftade på att > "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder > sig av termen Domain Services för att beskriva dessa "services" som kan > användas för att utföra denna typ av "koordinerade logik". Anledningen är > att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan > ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in > repositories etc till din calculate metod på order objektet. Men det blir > fort stökigt!
> Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er > som kommer från WCF?
> Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa > en ViewModel som du binder UI:t mot. På denna model kan du lägga en
> public decimal OrderTotal > get return model.OrderLines.Sum(l=>l.Price);
> I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för > att fylla denna modell med data.
> > btw du har rätt om att beräkningslogiken skall kunna ligga på andra > > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > > arbetar med. > > För att förenkla och minska behovet av att skriva antalet kodrader.
> > On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > > Kan du inte lägga den logiken i en class som du delar mellan client och > server? Ie
> > > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta > är beroende av moms, valutakurser, rabattberäkningar etc.
> > > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > > fakturarad t.ex. > > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > > något som räknas ut, men jag vill att användaren skall kunna se > > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > > >>> trycker på ovan är att jag absolut inte vill ha get; set> > funktionalitet > > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man > ändrar > > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > > > >>> låter som om det är en hybrid mellan DTO:er och domän object du > skickar > > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende > så > > > >>> renodlade sådana blir bara ett class med en massa auto properties > på. Ie > > > >>> helt ok med get;set; > > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, > den> > > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> > Men > > > >>> med automapper så fungerar ju inte det.Automapper används bara för > att > > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en > podcast > > > >>> på elegant > > > >>> code: > http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> > > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara > är > > > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > > >> ofta måste använda nått form av "repository" för att först ladda > > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > > > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att > det > > > >> är enklare att tänka så :) ) till servicelagret som: > > > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt > command > > > >> + ev. defaults)4. Sparar på något sätt > > > >> Exempel: > > > >> På client: > > > >> wcf/nservicebus/masstransit/whatever.Send(new > UpdateCustomerStatusCommand > > > >> ...) > > > >> På server > > > >> public class UpdateCustomerStatusHandler: IHandleMessage< > > > >> UpdateCustomerStatusCommand >{ > > > >> public Handle(UpdateCustomerStatusCommand command) { > > > >> var customerToUpdate > > > >> =repository.Get<Customer>(command.CustomerId); > > > >> customerToUpdate.ChangeStatus( command.NewStatus); > > > >> repository.Update(customerToUpdate); }}
> > > >>> Problemet med att en Automapper inte löser mina program, det jag > > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > > >>> funktionalitet på alla medlemsvariabler. > > > >>> Visa variabler vill jag inte att man ändrar via en property utan > skall > > > >>> räknas ut eller sättas via en metod.
> > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, > den > > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > > >>> Men med automapper så fungerar ju inte det.
> > > >>> Därför söker jag andra lösningar. Jag vill inte heller att all > logik > > > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > > > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > > > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > > > >>> entitet som viewmodel arbetar mot.
> > > >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och > server.. Ta > > > >>> mot > > > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för > att > > > >>> > underlätta mappning.
> > > >>> > Aspen projektet tillsammans med MS kommer att göra precis det, > eller > > > >>> den gör > > > >>> > det idag men har inte hunnit blogga om det.. här är min senate > post:
Japp det är en bra lösning så länge man hela tiden tänker på "the fallacies of distributed computing" så att man inte råkar ut för prestandaproblem etc på grund av att man skapar för finkorning wcf-tjänster som resulterar i för mycket trafik över nätverket.http://en.wikipedia.org/wiki/Fallacies_of_Distributed_ComputingPå svenska: Se till att inte skjuta dig själv i foten genom en massa for loopar som genererar för många anrop till servern :)/Andreas http://andreasohlund.blogspot.com
Date: Fri, 22 Jan 2010 16:51:54 +0100 Subject: Re: Silverlight, DTO, DDD From: patrik.lowend...@gmail.com To: sweden-altnet@googlegroups.com
Jo, det är en vanlig och riktigt bra lösning.
Repositoryt bryr ju sig egentligen inte om vad "storage" är för något utan är bara intresserat av att få ut BE objekt från någon annastans. Oftast brukar det här inte vara just en "Repository" dock utan mer en "proxy" som använder en translator på insidan.
Jag kan egentligen på tok för lite både om Silverlight och problematiken ni diskuterar för att lägga mig i, men...
Kan man inte likställa kommunikationen i WCF med den mot en databas? Dvs, kan man inte ha ett Repository på klienten som arbetar mot WCF på samma sätt som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive BL istället för dumma DTO:er. Och kanske även bygga en identity map på klientsidan som garanterar att endast en instans finns av varje entitet.
Din Service är ett Service lager, ett fönster in till din business logik. Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska inte låta dina domain entiteter bära på datakontrakts information. Skicka den data klienten behöver (Många anser att REST-Service är bäst för RIA, jag säger "det beror på"). På klienten har du en ViewModel. En modell skapad för att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas sa, ska du beräkna pris på klienten utan att du behöver göra server anrop, lägg då den logiken i ViewModel.. ska inte ligga på det objekt du skickar över nätet.. det är fortfarande bara data/message som du skickar inte ett "Object".
Den typ av business logik som ska finnas på klient har enbart med att få upp svarstider på UI.. och skapa en bra användarupplevelse, all annan logik ska placeras på servern.
Viss logik kommer att ligga både på server och klient. Denna logic ska gärna skrivas med samma språk för att underhåll ska bli så enkelt som möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt om). Så då blir det lättare att dela business logik på båda ställen i en enda komponent. Idag så får du ha det på två, eller köra med WCF RIA Services.
Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och vissa saker som du kanske vill göra eller ska göra, blir onödigt komplex.. så väl den modell som passar dig och ditt business case bäst.
Mvh Fredrik Normén
From: Andreas Öhlund Sent: Friday, January 22, 2010 11:08 AM To: sweden-altnet@googlegroups.com Subject: RE: Silverlight, DTO, DDD
Det var inte min mening att framstå som anti OO. Jag syftade på att "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder sig av termen Domain Services för att beskriva dessa "services" som kan användas för att utföra denna typ av "koordinerade logik". Anledningen är att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in repositories etc till din calculate metod på order objektet. Men det blir fort stökigt!
Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er som kommer från WCF?
Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa en ViewModel som du binder UI:t mot. På denna model kan du lägga en
public decimal OrderTotal get return model.OrderLines.Sum(l=>l.Price);
I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för att fylla denna modell med data.
> Date: Fri, 22 Jan 2010 01:34:33 -0800 > Subject: Re: Silverlight, DTO, DDD > From: pehrs...@gmail.com > To: sweden-altnet@googlegroups.com
> btw du har rätt om att beräkningslogiken skall kunna ligga på andra > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > arbetar med. > För att förenkla och minska behovet av att skriva antalet kodrader.
> On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> > /Andreas
> > ________________________
> > On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > fakturarad t.ex.
> > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > något som räknas ut, men jag vill att användaren skall kunna se
> > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote:
> > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det
> > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie
> > >>> helt ok med get;set; > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men
> > >>> med automapper så fungerar ju inte det.Automapper används bara för att > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > > >>> på elegant
> > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är
> > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > >> ofta måste använda nått form av "repository" för att först ladda > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag
> > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > > >> är enklare att tänka så :) ) till servicelagret som:
> > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > > >> + ev. defaults)4. Sparar på något sätt
> > >> Exempel: > > >> På client: > > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > > >> ...) > > >> På server > > >> public class UpdateCustomerStatusHandler: IHandleMessage<
> > >>> From: pehrs...@gmail.com > > >>> To: sweden-altnet@googlegroups.com
> > >>> Problemet med att en Automapper inte löser mina program, det jag > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > >>> funktionalitet på alla medlemsvariabler.
> > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > > >>> räknas ut eller sättas via en metod.
> > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den
> > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > >>> Men med automapper så fungerar ju inte det.
> > >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik
> > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en
> > >>> entitet som viewmodel arbetar mot.
> > >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote:
> > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > > >>> mot > > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att
Det är väldigt vanligt att man vill bryta ut service anropen från ViewModel i något vissa kallar för Model och vissa för något helt annat.. Vad det handlar om är att kunna enkelt få bort beroenden till själva proxyn som anropar tjänsten. På så vis kan man också enklare testa sin ViewModel. Jag skulle inte vilja kalla det en Repository.. En kallade det för DataChannel. Så det namnet tog jag.. det blev:
View -> ViewModel -> IxxxxDataChannel -> Proxy <-> (DTO) <-> Service (Transform) -> Domain Model
Det viktiga är att se Silverlight som en RIA.. där man inte applicerar en domän model till på klientsidan, utan ser SL som Presentationslagret. När det kommer till SL OOB, då börjar vi prata mer om att använda SL till att skapa dekstop apps..
/Fredrik N
From: Torbjörn Kalin Sent: Friday, January 22, 2010 4:49 PM To: sweden-altnet@googlegroups.com Subject: Re: Silverlight, DTO, DDD
Jag kan egentligen på tok för lite både om Silverlight och problematiken ni diskuterar för att lägga mig i, men...
Kan man inte likställa kommunikationen i WCF med den mot en databas? Dvs, kan man inte ha ett Repository på klienten som arbetar mot WCF på samma sätt som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive BL istället för dumma DTO:er. Och kanske även bygga en identity map på klientsidan som garanterar att endast en instans finns av varje entitet.
----- Original Message ----- From: fnor...@hotmail.com To: sweden-altnet@googlegroups.com Sent: Friday, January 22, 2010 11:29 AM Subject: Re: Silverlight, DTO, DDD
Note: Min svenska suger fett, så ni bara vet...
Det heter Model View ViewModel :P
DTOer är tillför att begränsa data och för att inte exponera business object över nätet. Läs gärna om DTO här:
Din Service är ett Service lager, ett fönster in till din business logik. Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska inte låta dina domain entiteter bära på datakontrakts information. Skicka den data klienten behöver (Många anser att REST-Service är bäst för RIA, jag säger "det beror på"). På klienten har du en ViewModel. En modell skapad för att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas sa, ska du beräkna pris på klienten utan att du behöver göra server anrop, lägg då den logiken i ViewModel.. ska inte ligga på det objekt du skickar över nätet.. det är fortfarande bara data/message som du skickar inte ett "Object".
Den typ av business logik som ska finnas på klient har enbart med att få upp svarstider på UI.. och skapa en bra användarupplevelse, all annan logik ska placeras på servern.
Viss logik kommer att ligga både på server och klient. Denna logic ska gärna skrivas med samma språk för att underhåll ska bli så enkelt som möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt om). Så då blir det lättare att dela business logik på båda ställen i en enda komponent. Idag så får du ha det på två, eller köra med WCF RIA Services.
Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och vissa saker som du kanske vill göra eller ska göra, blir onödigt komplex.. så väl den modell som passar dig och ditt business case bäst.
Mvh Fredrik Normén
From: Andreas Öhlund Sent: Friday, January 22, 2010 11:08 AM To: sweden-altnet@googlegroups.com Subject: RE: Silverlight, DTO, DDD
Det var inte min mening att framstå som anti OO. Jag syftade på att "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder sig av termen Domain Services för att beskriva dessa "services" som kan användas för att utföra denna typ av "koordinerade logik". Anledningen är att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in repositories etc till din calculate metod på order objektet. Men det blir fort stökigt!
Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er som kommer från WCF?
Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa en ViewModel som du binder UI:t mot. På denna model kan du lägga en
public decimal OrderTotal get return model.OrderLines.Sum(l=>l.Price);
I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för att fylla denna modell med data.
> Date: Fri, 22 Jan 2010 01:34:33 -0800 > Subject: Re: Silverlight, DTO, DDD > From: pehrs...@gmail.com > To: sweden-altnet@googlegroups.com
> btw du har rätt om att beräkningslogiken skall kunna ligga på andra > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > arbetar med. > För att förenkla och minska behovet av att skriva antalet kodrader.
> On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > Kan du inte lägga den logiken i en class som du delar mellan client och server? Ie
> > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta är beroende av moms, valutakurser, rabattberäkningar etc.
> > /Andreas
> > ________________________
> > On 2010-01-22 10:04:09 +0100 Niclas Pehrsson <pehrs...@gmail.com> wrote:
> > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > fakturarad t.ex. > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > något som räknas ut, men jag vill att användaren skall kunna se > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > >>> trycker på ovan är att jag absolut inte vill ha get; set> funktionalitet > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man ändrar > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > > >>> låter som om det är en hybrid mellan DTO:er och domän object du skickar > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende så > > >>> renodlade sådana blir bara ett class med en massa auto properties på. Ie > > >>> helt ok med get;set; > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den> > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> Men > > >>> med automapper så fungerar ju inte det.Automapper används bara för att > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en podcast > > >>> på elegant > > >>> code:http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara är > > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > >> ofta måste använda nått form av "repository" för att först ladda > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att det > > >> är enklare att tänka så :) ) till servicelagret som: > > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt command > > >> + ev. defaults)4. Sparar på något sätt > > >> Exempel: > > >> På client: > > >> wcf/nservicebus/masstransit/whatever.Send(new UpdateCustomerStatusCommand > > >> ...) > > >> På server > > >> public class UpdateCustomerStatusHandler: IHandleMessage< > > >> UpdateCustomerStatusCommand >{ > > >> public Handle(UpdateCustomerStatusCommand command) { > > >> var customerToUpdate > > >> =repository.Get<Customer>(command.CustomerId); > > >> customerToUpdate.ChangeStatus( command.NewStatus); > > >> repository.Update(customerToUpdate); }}
> > >>> Problemet med att en Automapper inte löser mina program, det jag > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > >>> funktionalitet på alla medlemsvariabler. > > >>> Visa variabler vill jag inte att man ändrar via en property utan skall > > >>> räknas ut eller sättas via en metod.
> > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, den > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > >>> Men med automapper så fungerar ju inte det.
> > >>> Därför söker jag andra lösningar. Jag vill inte heller att all logik > > >>> skall avgöras av min viewmodel då den enligt mig inte skall ha > > >>> affärslogik som att räkna ut vad slutsumman blir på antalet > > >>> fakturarader t.ex. det är funktionalitet jag vill kunna ha i en > > >>> entitet som viewmodel arbetar mot.
> > >>> On 21 Jan, 21:47, Fredrik Normén <fnor...@hotmail.com> wrote: > > >>> > Kör med MVVM på klienten.. skicka DTOer mellan client och server.. Ta > > >>> mot > > >>> > DTOer, och i ditt service lager kan du köra med AutoMapper för att
Det är precis detta jag vill uppnå och som jag kan uppnå på ett enkelt sätt, problemet är bara att vid överskickandet WCF till Silverlight så finns det en begränsning som inte kan deserializera eller serialisera ner objekt med privata listor och datatyper eftersom de behöver get; set; och get set på allting vill jag inte ha i en domänmodell som jag gärna skulle vilja dela mellan klient och servicelayer. Eftersom jag som sagt inte vill fråga min service räkna ut totalpriset av min order varje gång jag ändrar ett värde på en orderrad eller lägger till något.Utan här vill jag kunna arbeta klart med ordern på klienten utan att fråga servern om information hela tiden.
On 22 Jan, 16:51, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote:
> Repositoryt bryr ju sig egentligen inte om vad "storage" är för något utan > är bara intresserat av att få ut BE objekt från någon annastans. Oftast > brukar det här inte vara just en "Repository" dock utan mer en "proxy" som > använder en translator på insidan.
> > Jag kan egentligen på tok för lite både om Silverlight och problematiken > > ni diskuterar för att lägga mig i, men...
> > Kan man inte likställa kommunikationen i WCF med den mot en databas? Dvs, > > kan man inte ha ett Repository på klienten som arbetar mot WCF på samma sätt > > som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive BL > > istället för dumma DTO:er. Och kanske även bygga en identity map på > > klientsidan som garanterar att endast en instans finns av varje entitet.
> > /T
> > ----- Original Message ----- > > *From:* fnor...@hotmail.com > > *To:* sweden-altnet@googlegroups.com > > *Sent:* Friday, January 22, 2010 11:29 AM > > *Subject:* Re: Silverlight, DTO, DDD
> > Note: Min svenska suger fett, så ni bara vet...
> > Det heter Model View ViewModel :P
> > DTOer är tillför att begränsa data och för att inte exponera business > > object över nätet. Läs gärna om DTO här:
> > Din Service är ett Service lager, ett fönster in till din business logik. > > Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska inte > > låta dina domain entiteter bära på datakontrakts information. Skicka den > > data klienten behöver (Många anser att REST-Service är bäst för RIA, jag > > säger "det beror på"). På klienten har du en ViewModel. En modell skapad för > > att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas sa, > > ska du beräkna pris på klienten utan att du behöver göra server anrop, lägg > > då den logiken i ViewModel.. ska inte ligga på det objekt du skickar över > > nätet.. det är fortfarande bara data/message som du skickar inte ett > > "Object".
> > Den typ av business logik som ska finnas på klient har enbart med att få > > upp svarstider på UI.. och skapa en bra användarupplevelse, all annan logik > > ska placeras på servern.
> > Viss logik kommer att ligga både på server och klient. Denna logic ska > > gärna skrivas med samma språk för att underhåll ska bli så enkelt som > > möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt om). Så > > då blir det lättare att dela business logik på båda ställen i en enda > > komponent. Idag så får du ha det på två, eller köra med WCF RIA Services.
> > Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och > > vissa saker som du kanske vill göra eller ska göra, blir onödigt komplex.. > > så väl den modell som passar dig och ditt business case bäst.
> > Mvh Fredrik Normén
> > *From:* Andreas Öhlund <andreas_ohl...@hotmail.com> > > *Sent:* Friday, January 22, 2010 11:08 AM > > *To:* sweden-altnet@googlegroups.com > > *Subject:* RE: Silverlight, DTO, DDD
> > Det var inte min mening att framstå som anti OO. Jag syftade på att > > "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans använder > > sig av termen Domain Services för att beskriva dessa "services" som kan > > användas för att utföra denna typ av "koordinerade logik". Anledningen är > > att du tex kanske måste slå mot en DB för att få valuta kurser innan du kan > > ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka in > > repositories etc till din calculate metod på order objektet. Men det blir > > fort stökigt!
> > Är inte problemet i ditt fall att du renderar ditt UI direkt mot de DTO:er > > som kommer från WCF?
> > Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs skapa > > en ViewModel som du binder UI:t mot. På denna model kan du lägga en
> > public decimal OrderTotal > > get return model.OrderLines.Sum(l=>l.Price);
> > I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller för > > att fylla denna modell med data.
> > > btw du har rätt om att beräkningslogiken skall kunna ligga på andra > > > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > > > arbetar med. > > > För att förenkla och minska behovet av att skriva antalet kodrader.
> > > On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > > > Kan du inte lägga den logiken i en class som du delar mellan client och > > server? Ie
> > > > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > > > Den här typen av beräkningar bör oftast inte ligga på Order då den ofta > > är beroende av moms, valutakurser, rabattberäkningar etc.
> > > > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att räkna > > > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > > > fakturarad t.ex. > > > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > > > något som räknas ut, men jag vill att användaren skall kunna se > > > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > > > >>> trycker på ovan är att jag absolut inte vill ha get; set> > > funktionalitet > > > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man > > ändrar > > > > >>> via en property utan skall> räknas ut eller sättas via en metod.Det > > > > >>> låter som om det är en hybrid mellan DTO:er och domän object du > > skickar > > > > >>> mellan client och server. DTO:er skall inte innehålla nått beteende > > så > > > > >>> renodlade sådana blir bara ett class med en massa auto properties > > på. Ie > > > > >>> helt ok med get;set; > > > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, > > den> > > > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras.> > > Men > > > > >>> med automapper så fungerar ju inte det.Automapper används bara för > > att > > > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en > > podcast > > > > >>> på elegant > > > > >>> code: > >http://elegantcode.com/2009/10/29/code-cast-33-jimmy-bogard-on-automa...
> > > > >> Att mappa från andra håller funkar rätt dåligt då DTO:er ofta bara > > är > > > > >> ett subset av all data som domänobjektet innehåller. Det gör att man > > > > >> ofta måste använda nått form av "repository" för att först ladda > > > > >> domänobjektet och sedan lägga på den data som DTO:n innehåller. Jag > > > > >> brukar försöka lösa det så att när gui vill uppdatera så skickar det > > > > >> ett "Command"(det är ju egentligen oxå en DTO men jag jag tycker att > > det > > > > >> är enklare att tänka så :) ) till servicelagret som: > > > > >> 1. Validerar datat2. Laddar de ev domänobjekt som är inblandande och > > > > >> uppdaterar datat3. Skapar ev. nya domänobjekt (med data från mitt > > command > > > > >> + ev. defaults)4. Sparar på något sätt > > > > >> Exempel: > > > > >> På client: > > > > >> wcf/nservicebus/masstransit/whatever.Send(new > > UpdateCustomerStatusCommand > > > > >> ...) > > > > >> På server > > > > >> public class UpdateCustomerStatusHandler: IHandleMessage< > > > > >> UpdateCustomerStatusCommand >{ > > > > >> public Handle(UpdateCustomerStatusCommand command) { > > > > >> var customerToUpdate > > > > >> =repository.Get<Customer>(command.CustomerId); > > > > >> customerToUpdate.ChangeStatus( command.NewStatus); > > > > >> repository.Update(customerToUpdate); }}
> > > > >>> Problemet med att en Automapper inte löser mina program, det jag > > > > >>> trycker på ovan är att jag absolut inte vill ha get; set > > > > >>> funktionalitet på alla medlemsvariabler. > > > > >>> Visa variabler vill jag inte att man ändrar via en property utan > > skall > > > > >>> räknas ut eller sättas via en metod.
> > > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer property, > > den > > > > >>> propertyn bör det enbart sitta set på för den ska aldrig ändras. > > > > >>> Men med automapper så fungerar ju inte det.
Fast jag tror inte riktigt det jag försökte förklara gick fram, så jag försöker igen.
Du kan absolut dela ditt BE library mellan klient och server om du vill, äger du båda sidorna så är det ok. Men i kommunikationen mellan klient och server är det inte BE objekten optimalt att serializera / deserializera utan en bättre strategi är att designa service-gränssnitt som är specialiserade för exakt den operation du vill utföra. Det innebär att man oftast mår bäst av att skapa separata datakontrakt som är optimerade för just kommunikation mellan server och klient och inte nödvändigtvis optimerade för att fånga domänen. Just ditt scenario visar ju dessutom på behovet, inget är privat i xml, vilket är det som skickas över tråden, men du vill dölja det faktumet i din domänmodell.
Så tipset, lösningen och rekommendationen är att skapa särskilda DTO'er som är specialdesignade för de operationer du vill utföra. Om du dessutom lägger till Fredriks rekommendation om att du skall ha en presentationsmodell i SL och inte den riktiga domänmodellen som istället borde bo bara på backend, så blir rekommendationen tre olika modeller. En på backend, en för wcf-gränsnitten och en för frontend.
Att man vill ha en på frontend som fredrik föreslår, har många fördelar, men de två som jag brukar lyfta fram är att man för det första inte kan veta vilka funktioner i en domänmodell som är tänkta att användas på frontend eller backend (du kommer ju åt dem på båda ställena) och för det andra så är ju presentationen av modellen väldigt ofta skilt från att jobba med affärslogik i modellen, det är ju två olika syften.
Sen är det ju också så att du kan ha privata medlemmar på backend som du exponerar via datamember attributet, men SL kräver att de är publika på frontend. Men det visste du så klart redan :)
> Det är precis detta jag vill uppnå och som jag kan uppnå på ett enkelt > sätt, problemet är bara att vid överskickandet WCF till Silverlight så > finns det en begränsning som inte kan deserializera eller serialisera > ner objekt med privata listor och datatyper eftersom de behöver get; > set; och get set på allting vill jag inte ha i en domänmodell som jag > gärna skulle vilja dela mellan klient och servicelayer. Eftersom jag > som sagt inte vill fråga min service räkna ut totalpriset av min order > varje gång jag ändrar ett värde på en orderrad eller lägger till > något.Utan här vill jag kunna arbeta klart med ordern på klienten utan > att fråga servern om information hela tiden.
> On 22 Jan, 16:51, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: > > Jo, det är en vanlig och riktigt bra lösning.
> > Repositoryt bryr ju sig egentligen inte om vad "storage" är för något > utan > > är bara intresserat av att få ut BE objekt från någon annastans. Oftast > > brukar det här inte vara just en "Repository" dock utan mer en "proxy" > som > > använder en translator på insidan.
> > > Jag kan egentligen på tok för lite både om Silverlight och > problematiken > > > ni diskuterar för att lägga mig i, men...
> > > Kan man inte likställa kommunikationen i WCF med den mot en databas? > Dvs, > > > kan man inte ha ett Repository på klienten som arbetar mot WCF på samma > sätt > > > som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive > BL > > > istället för dumma DTO:er. Och kanske även bygga en identity map på > > > klientsidan som garanterar att endast en instans finns av varje > entitet.
> > > Din Service är ett Service lager, ett fönster in till din business > logik. > > > Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska > inte > > > låta dina domain entiteter bära på datakontrakts information. Skicka > den > > > data klienten behöver (Många anser att REST-Service är bäst för RIA, > jag > > > säger "det beror på"). På klienten har du en ViewModel. En modell > skapad för > > > att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas > sa, > > > ska du beräkna pris på klienten utan att du behöver göra server anrop, > lägg > > > då den logiken i ViewModel.. ska inte ligga på det objekt du skickar > över > > > nätet.. det är fortfarande bara data/message som du skickar inte ett > > > "Object".
> > > Den typ av business logik som ska finnas på klient har enbart med att > få > > > upp svarstider på UI.. och skapa en bra användarupplevelse, all annan > logik > > > ska placeras på servern.
> > > Viss logik kommer att ligga både på server och klient. Denna logic ska > > > gärna skrivas med samma språk för att underhåll ska bli så enkelt som > > > möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt > om). Så > > > då blir det lättare att dela business logik på båda ställen i en enda > > > komponent. Idag så får du ha det på två, eller köra med WCF RIA > Services.
> > > Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och > > > vissa saker som du kanske vill göra eller ska göra, blir onödigt > komplex.. > > > så väl den modell som passar dig och ditt business case bäst.
> > > Mvh Fredrik Normén
> > > *From:* Andreas Öhlund <andreas_ohl...@hotmail.com> > > > *Sent:* Friday, January 22, 2010 11:08 AM > > > *To:* sweden-altnet@googlegroups.com > > > *Subject:* RE: Silverlight, DTO, DDD
> > > Det var inte min mening att framstå som anti OO. Jag syftade på att > > > "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans > använder > > > sig av termen Domain Services för att beskriva dessa "services" som kan > > > användas för att utföra denna typ av "koordinerade logik". Anledningen > är > > > att du tex kanske måste slå mot en DB för att få valuta kurser innan du > kan > > > ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka > in > > > repositories etc till din calculate metod på order objektet. Men det > blir > > > fort stökigt!
> > > Är inte problemet i ditt fall att du renderar ditt UI direkt mot de > DTO:er > > > som kommer från WCF?
> > > Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs > skapa > > > en ViewModel som du binder UI:t mot. På denna model kan du lägga en
> > > public decimal OrderTotal > > > get return model.OrderLines.Sum(l=>l.Price);
> > > I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller > för > > > att fylla denna modell med data.
> > > > btw du har rätt om att beräkningslogiken skall kunna ligga på andra > > > > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > > > > arbetar med. > > > > För att förenkla och minska behovet av att skriva antalet kodrader.
> > > > On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > > > > Kan du inte lägga den logiken i en class som du delar mellan client > och > > > server? Ie
> > > > > var orderTotal = priceCalculator.CalculateTotalFor(order);
> > > > > Den här typen av beräkningar bör oftast inte ligga på Order då den > ofta > > > är beroende av moms, valutakurser, rabattberäkningar etc.
> > > > > > Jo men jag vill knappast anropa mitt servicelager (WCF) för att > räkna > > > > > > ut vad totalsumman på min faktura blir när jag lägger till en > > > > > > fakturarad t.ex. > > > > > > Jag vill inte att alla beräkningar skall ligga på serversidan. > > > > > > Totalsumman kommer jag inte att skicka över sedan eftersom det är > > > > > > något som räknas ut, men jag vill att användaren skall kunna se > > > > > > totalsumman direkt när raden är tillagd utan ett serviceanrop.
> > > > > > On 22 Jan, 09:17, Andreas Öhlund <andreas_ohl...@hotmail.com> > wrote: > > > > > >>> trycker på ovan är att jag absolut inte vill ha get; set> > > > funktionalitet > > > > > >>> på alla medlemsvariabler.> Visa variabler vill jag inte att man > > > ändrar > > > > > >>> via en property utan skall> räknas ut eller sättas via en > metod.Det > > > > > >>> låter som om det är en hybrid mellan DTO:er och domän object du > > > skickar > > > > > >>> mellan client och server. DTO:er skall inte innehålla nått > beteende > > > så > > > > > >>> renodlade sådana blir bara ett class med en massa auto > properties > > > på. Ie > > > > > >>> helt ok med get;set; > > > > > >>> Säg t.ex. att mitt objekt har en Id eller Artikelnummer > property, > > > den> > > > > > >>> propertyn bör det enbart sitta set på för den ska aldrig > ändras.> > > > Men > > > > > >>> med automapper så fungerar ju inte det.Automapper används bara > för > > > att > > > > > >>> mappa från domän till DTO. Jimmy Bogard förklarar detta i en > > > podcast > > > > > >>> på elegant > > > > > >>> code:
Ja det jag är ute efter är att kunna dela mina BE på båda sidor, där jag använder mig av ViewModel's på Silverlight för presentation. Min fråga var just det jag skrev ovan, hur jag på ett smidigt sätt kan skicka över datan och omvandla Entitet till DTO på servicen och tvärtom på klienten. Som jag beskriver i mitt första inlägg så går detta utmärkt utan att ens behöva tänka på det i en WPF & WCF miljö om man sätter [Serializeable] på objektet så klarar WCF av att bara serializera ner mina fält som ligger på objektet och sedan deserializera det på klienten. Dvs vid ett objekt som ser ut följande.
public decimal TotalPrice { get { return _unitPrice * _quantity; }}
Så skickas bara fälten över vilket är utmärkt när jag på andra sidan kan få in datan i samma entitet. (läs mer här fungerar efter .NET 3.5 SP1 http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/5... , lite längre ner på sidan finns en summary det är alternativ 2 jag syftar på där man inte behöver använda sig av attributes)
Men vid användning av Silverlight så fungerar inte Serializeable p.g.a. dåligt stöd av reflection.
Men säg t.ex. här att _quantity bara går att ändra med en metod p.g.a. olika kontroller eller what ever dvs man har ingen set property för den.
Så min grundfråga hur får jag samma resultat som tidigare med DTO:er utan att skräpa ner min domänmodell för mycket? Är det en extra konstruktor på mitt objekt som tar emot DTO:n och sätter värdena på sig själv och en metod som retunerar ungefär så som ISerializeable interfacet fungerar? Eller finns det trevligare lösningar?
On 23 Jan, 12:23, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote:
> Fast jag tror inte riktigt det jag försökte förklara gick fram, så jag > försöker igen.
> Du kan absolut dela ditt BE library mellan klient och server om du vill, > äger du båda sidorna så är det ok. Men i kommunikationen mellan klient och > server är det inte BE objekten optimalt att serializera / deserializera utan > en bättre strategi är att designa service-gränssnitt som är specialiserade > för exakt den operation du vill utföra. Det innebär att man oftast mår bäst > av att skapa separata datakontrakt som är optimerade för just kommunikation > mellan server och klient och inte nödvändigtvis optimerade för att fånga > domänen. Just ditt scenario visar ju dessutom på behovet, inget är privat i > xml, vilket är det som skickas över tråden, men du vill dölja det faktumet i > din domänmodell.
> Så tipset, lösningen och rekommendationen är att skapa särskilda DTO'er som > är specialdesignade för de operationer du vill utföra. Om du dessutom lägger > till Fredriks rekommendation om att du skall ha en presentationsmodell i SL > och inte den riktiga domänmodellen som istället borde bo bara på backend, så > blir rekommendationen tre olika modeller. En på backend, en för > wcf-gränsnitten och en för frontend.
> Att man vill ha en på frontend som fredrik föreslår, har många fördelar, > men de två som jag brukar lyfta fram är att man för det första inte kan veta > vilka funktioner i en domänmodell som är tänkta att användas på frontend > eller backend (du kommer ju åt dem på båda ställena) och för det andra så är > ju presentationen av modellen väldigt ofta skilt från att jobba med > affärslogik i modellen, det är ju två olika syften.
> Sen är det ju också så att du kan ha privata medlemmar på backend som du > exponerar via datamember attributet, men SL kräver att de är publika på > frontend. Men det visste du så klart redan :)
> > Det är precis detta jag vill uppnå och som jag kan uppnå på ett enkelt > > sätt, problemet är bara att vid överskickandet WCF till Silverlight så > > finns det en begränsning som inte kan deserializera eller serialisera > > ner objekt med privata listor och datatyper eftersom de behöver get; > > set; och get set på allting vill jag inte ha i en domänmodell som jag > > gärna skulle vilja dela mellan klient och servicelayer. Eftersom jag > > som sagt inte vill fråga min service räkna ut totalpriset av min order > > varje gång jag ändrar ett värde på en orderrad eller lägger till > > något.Utan här vill jag kunna arbeta klart med ordern på klienten utan > > att fråga servern om information hela tiden.
> > On 22 Jan, 16:51, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: > > > Jo, det är en vanlig och riktigt bra lösning.
> > > Repositoryt bryr ju sig egentligen inte om vad "storage" är för något > > utan > > > är bara intresserat av att få ut BE objekt från någon annastans. Oftast > > > brukar det här inte vara just en "Repository" dock utan mer en "proxy" > > som > > > använder en translator på insidan.
> > > > Jag kan egentligen på tok för lite både om Silverlight och > > problematiken > > > > ni diskuterar för att lägga mig i, men...
> > > > Kan man inte likställa kommunikationen i WCF med den mot en databas? > > Dvs, > > > > kan man inte ha ett Repository på klienten som arbetar mot WCF på samma > > sätt > > > > som man jobbar mot sin ORM. Skicka över riktiga domänobjekt inklusive > > BL > > > > istället för dumma DTO:er. Och kanske även bygga en identity map på > > > > klientsidan som garanterar att endast en instans finns av varje > > entitet.
> > > > Din Service är ett Service lager, ett fönster in till din business > > logik. > > > > Kör du med WCF så skapar du DTOer med hjälp av Datakontrakt, du ska > > inte > > > > låta dina domain entiteter bära på datakontrakts information. Skicka > > den > > > > data klienten behöver (Många anser att REST-Service är bäst för RIA, > > jag > > > > säger "det beror på"). På klienten har du en ViewModel. En modell > > skapad för > > > > att mappas till ditt UI och ska bära på komplex UI logic.. Som Andreas > > sa, > > > > ska du beräkna pris på klienten utan att du behöver göra server anrop, > > lägg > > > > då den logiken i ViewModel.. ska inte ligga på det objekt du skickar > > över > > > > nätet.. det är fortfarande bara data/message som du skickar inte ett > > > > "Object".
> > > > Den typ av business logik som ska finnas på klient har enbart med att > > få > > > > upp svarstider på UI.. och skapa en bra användarupplevelse, all annan > > logik > > > > ska placeras på servern.
> > > > Viss logik kommer att ligga både på server och klient. Denna logic ska > > > > gärna skrivas med samma språk för att underhåll ska bli så enkelt som > > > > möjligt. Med SL4 så kan .NET CLRn köra mot SL4 class lib (inte tvärt > > om). Så > > > > då blir det lättare att dela business logik på båda ställen i en enda > > > > komponent. Idag så får du ha det på två, eller köra med WCF RIA > > Services.
> > > > Jag vill bara säg att allt BEROR på! Det finns ingen Silver bullet och > > > > vissa saker som du kanske vill göra eller ska göra, blir onödigt > > komplex.. > > > > så väl den modell som passar dig och ditt business case bäst.
> > > > Det var inte min mening att framstå som anti OO. Jag syftade på att > > > > "calculate" metoder sällan bör ligga på domänklasserna. Eric Evans > > använder > > > > sig av termen Domain Services för att beskriva dessa "services" som kan > > > > användas för att utföra denna typ av "koordinerade logik". Anledningen > > är > > > > att du tex kanske måste slå mot en DB för att få valuta kurser innan du > > kan > > > > ge ett slutgiltigt pris etc etc. Alternativet till detta är att skicka > > in > > > > repositories etc till din calculate metod på order objektet. Men det > > blir > > > > fort stökigt!
> > > > Är inte problemet i ditt fall att du renderar ditt UI direkt mot de > > DTO:er > > > > som kommer från WCF?
> > > > Som Fredrik nämnde så är ett sätt att lösa detta att köra MVVM. Dvs > > skapa > > > > en ViewModel som du binder UI:t mot. På denna model kan du lägga en
> > > > public decimal OrderTotal > > > > get return model.OrderLines.Sum(l=>l.Price);
> > > > I så fall använder du DTO:erna som din Model (sista M:et i MVVM), eller > > för > > > > att fylla denna modell med data.
> > > > > btw du har rätt om att beräkningslogiken skall kunna ligga på andra > > > > > ställen men jag vill att den skall kunna ligga i mitt objekt som jag > > > > > arbetar med. > > > > > För att förenkla och minska behovet av att skriva antalet kodrader.
> > > > > On 22 Jan, 10:27, Andreas Öhlund <andreas_ohl...@hotmail.com> wrote: > > > > > > Kan du inte lägga den logiken i en class som du delar mellan
I WCF skapar du ett datakontrakt.. detta r din DTO
I din WCF Service s mappar du din Entites mot detta datakontrakt innan du returnerar det..
Tex:
public IEnumerable<MemberDto> GetMembers() { var members = _memberRepository.GetAll();
return members.Select( m => { return new MemberDto() { ID = m.ID, FirstName = m.FirstName, LastName = m.LastName }; }); }
AutoMapper kan hj lpa dig med mappningen..
Lite mer info om DTO: "My First Law of Distributed Object Design: Don't distribute your objects" - Martin Fowler (P of EAA)
"Objects have been around for a while, and sometimes it seems that ever since they were created, folks have wanted to distribute them. However, distribution of objects, or indeed of anything else, has a lot more pitfalls than many people realize, especially when they're under the influence of vendors' cozy brochures." - Martin Fowler (http://www.ddj.com/architect/184414966)
Instead of sharing a single entity implementation between the mid-tier and the client, we can create a custom object (DTO) that is only used for passing data over the wire. Most entities in our domain model is not often designed with distribution in mind. Using DTO have two main benefits regarding to Daniel Simmons (Architect on the Entity Framework team at Microsoft):
"It isolates your service contract from implementation issues on the mid-tier and the client, allowing that contract to remain stable even if the implementation on the tiers changes, and it allows you to control what data flows over the wire. Therefore, you can avoid sending unnecessary data (or data the client is not allowed to access) or reshape the data to make it more convenient for the service. Generally, the service contract is designed with the client scenarios in mind so that the data can be reshaped between the mid-tier entities and the DTOs (maybe by combining multiple entities into one DTO and skipping properties not needed on the client), while the DTOs can be used directly on the client.
These benefits, however, come at the price of having to create and maintain one or two more layers of objects and mapping." - Daniel Simmons (Building N-Tier Apps with EF4)
> Ja det jag r ute efter r att kunna dela mina BE p b da sidor, d r > jag anv nder mig av ViewModel's p Silverlight f r presentation. > Min fr ga var just det jag skrev ovan, hur jag p ett smidigt s tt kan > skicka ver datan och omvandla Entitet till DTO p servicen och > tv rtom p klienten. > Som jag beskriver i mitt f rsta inl gg s g r detta utm rkt utan att > ens beh va t nka p det i en WPF & WCF milj om man s tter > [Serializeable] p objektet > s klarar WCF av att bara serializera ner mina f lt som ligger p > objektet och sedan deserializera det p klienten. Dvs vid ett objekt > som ser ut f ljande.
> public decimal TotalPrice { get { return _unitPrice * _quantity; }}
> S skickas bara f lten ver vilket r utm rkt n r jag p andra sidan > kan f in datan i samma entitet. (l s mer h r fungerar efter .NET 3.5 > SP1 > http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/5... > , lite l ngre ner p sidan finns en summary det r alternativ 2 jag > syftar p d r man inte beh ver anv nda sig av attributes)
> Men vid anv ndning av Silverlight s fungerar inte Serializeable > p.g.a. d ligt st d av reflection.
> Men s g t.ex. h r att _quantity bara g r att ndra med en metod p.g.a. > olika kontroller eller what ever dvs man har ingen set property f r > den.
> S min grundfr ga hur f r jag samma resultat som tidigare med DTO:er > utan att skr pa ner min dom nmodell f r mycket? > r det en extra konstruktor p mitt objekt som tar emot DTO:n och > s tter v rdena p sig sj lv och en metod som retunerar ungef r s som > ISerializeable interfacet fungerar? > Eller finns det trevligare l sningar?
> On 23 Jan, 12:23, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: >> Fast jag tror inte riktigt det jag f rs kte f rklara gick fram, s jag >> f rs ker igen.
>> Du kan absolut dela ditt BE library mellan klient och server om du vill, >> ger du b da sidorna s r det ok. Men i kommunikationen mellan klient >> och >> server r det inte BE objekten optimalt att serializera / deserializera >> utan >> en b ttre strategi r att designa service-gr nssnitt som r >> specialiserade >> f r exakt den operation du vill utf ra. Det inneb r att man oftast m r >> b st >> av att skapa separata datakontrakt som r optimerade f r just >> kommunikation >> mellan server och klient och inte n dv ndigtvis optimerade f r att f nga >> dom nen. Just ditt scenario visar ju dessutom p behovet, inget r privat >> i >> xml, vilket r det som skickas ver tr den, men du vill d lja det >> faktumet i >> din dom nmodell.
>> S tipset, l sningen och rekommendationen r att skapa s rskilda DTO'er >> som >> r specialdesignade f r de operationer du vill utf ra. Om du dessutom >> l gger >> till Fredriks rekommendation om att du skall ha en presentationsmodell i >> SL >> och inte den riktiga dom nmodellen som ist llet borde bo bara p backend, >> s >> blir rekommendationen tre olika modeller. En p backend, en f r >> wcf-gr nsnitten och en f r frontend.
>> Att man vill ha en p frontend som fredrik f resl r, har m nga f rdelar, >> men de tv som jag brukar lyfta fram r att man f r det f rsta inte kan >> veta >> vilka funktioner i en dom nmodell som r t nkta att anv ndas p frontend >> eller backend (du kommer ju t dem p b da st llena) och f r det andra s >> r >> ju presentationen av modellen v ldigt ofta skilt fr n att jobba med >> aff rslogik i modellen, det r ju tv olika syften.
>> Sen r det ju ocks s att du kan ha privata medlemmar p backend som du >> exponerar via datamember attributet, men SL kr ver att de r publika p >> frontend. Men det visste du s klart redan :)
>> > Det r precis detta jag vill uppn och som jag kan uppn p ett enkelt >> > s tt, problemet r bara att vid verskickandet WCF till Silverlight s >> > finns det en begr nsning som inte kan deserializera eller serialisera >> > ner objekt med privata listor och datatyper eftersom de beh ver get; >> > set; och get set p allting vill jag inte ha i en dom nmodell som jag >> > g rna skulle vilja dela mellan klient och servicelayer. Eftersom jag >> > som sagt inte vill fr ga min service r kna ut totalpriset av min order >> > varje g ng jag ndrar ett v rde p en orderrad eller l gger till >> > n got.Utan h r vill jag kunna arbeta klart med ordern p klienten utan >> > att fr ga servern om information hela tiden.
>> > On 22 Jan, 16:51, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: >> > > Jo, det r en vanlig och riktigt bra l sning.
>> > > Repositoryt bryr ju sig egentligen inte om vad "storage" r f r n got >> > utan >> > > r bara intresserat av att f ut BE objekt fr n n gon annastans. >> > > Oftast >> > > brukar det h r inte vara just en "Repository" dock utan mer en >> > > "proxy" >> > som >> > > anv nder en translator p insidan.
>> > > > Jag kan egentligen p tok f r lite b de om Silverlight och >> > problematiken >> > > > ni diskuterar f r att l gga mig i, men...
>> > > > Kan man inte likst lla kommunikationen i WCF med den mot en >> > > > databas? >> > Dvs, >> > > > kan man inte ha ett Repository p klienten som arbetar mot WCF p >> > > > samma >> > s tt >> > > > som man jobbar mot sin ORM. Skicka ver riktiga dom nobjekt >> > > > inklusive >> > BL >> > > > ist llet f r dumma DTO:er. Och kanske ven bygga en identity map p >> > > > klientsidan som garanterar att endast en instans finns av varje >> > entitet.
>> > > > Din Service r ett Service lager, ett f nster in till din business >> > logik. >> > > > K r du med WCF s skapar du DTOer med hj lp av Datakontrakt, du ska >> > inte >> > > > l ta dina domain entiteter b ra p datakontrakts information. >> > > > Skicka >> > den >> > > > data klienten beh ver (M nga anser att REST-Service r b st f r >> > > > RIA, >> > jag >> > > > s ger "det beror p "). P klienten har du en ViewModel. En modell >> > skapad f r >> > > > att mappas till ditt UI och ska b ra p komplex UI logic.. Som
Jo jag känner till hans lag hehe.. och dom två saker som listas mot benefits anser jag inte väga över det jobbiga med att underhålla mappningen. Jo så långt är jag med hur du gör det till DTO problemet är hur du förvandlar DTO'n till entitet sedan på klienten. Om du lästen länken jag skickade med ovan så behöver man inte skapa någon DTO eller tillbaka det sker i bakgrunden. Så jag undrar om det finns något liknande tillvägagångsätt för Silverlight då det är spärrat p.g.a. sandboxen som omöjligör användandet av [Serializeable].
On 23 Jan, 19:58, Fredrik Normén <fnor...@hotmail.com> wrote:
> Lite mer info om DTO: > "My First Law of Distributed Object Design: Don't distribute your objects" - > Martin Fowler (P of EAA)
> "Objects have been around for a while, and sometimes it seems that ever > since they were created, folks have wanted to distribute them. However, > distribution of objects, or indeed of anything else, has a lot more pitfalls > than many people realize, especially when they're under the influence of > vendors' cozy brochures." - Martin Fowler > (http://www.ddj.com/architect/184414966)
> Instead of sharing a single entity implementation between the mid-tier and > the client, we can create a custom object (DTO) that is only used for > passing data over the wire. Most entities in our domain model is not often > designed with distribution in mind. Using DTO have two main benefits > regarding to Daniel Simmons (Architect on the Entity Framework team at > Microsoft):
> "It isolates your service contract from implementation issues on the > mid-tier and the client, allowing that contract to remain stable even if the > implementation on the tiers changes, and it allows you to control what data > flows over the wire. Therefore, you can avoid sending unnecessary data (or > data the client is not allowed to access) or reshape the data to make it > more convenient for the service. Generally, the service contract is designed > with the client scenarios in mind so that the data can be reshaped between > the mid-tier entities and the DTOs (maybe by combining multiple entities > into one DTO and skipping properties not needed on the client), while the > DTOs can be used directly on the client.
> These benefits, however, come at the price of having to create and maintain > one or two more layers of objects and mapping." - Daniel Simmons (Building > N-Tier Apps with EF4)
> > Ja det jag r ute efter r att kunna dela mina BE p b da sidor, d r > > jag anv nder mig av ViewModel's p Silverlight f r presentation. > > Min fr ga var just det jag skrev ovan, hur jag p ett smidigt s tt kan > > skicka ver datan och omvandla Entitet till DTO p servicen och > > tv rtom p klienten. > > Som jag beskriver i mitt f rsta inl gg s g r detta utm rkt utan att > > ens beh va t nka p det i en WPF & WCF milj om man s tter > > [Serializeable] p objektet > > s klarar WCF av att bara serializera ner mina f lt som ligger p > > objektet och sedan deserializera det p klienten. Dvs vid ett objekt > > som ser ut f ljande.
> > public decimal TotalPrice { get { return _unitPrice * _quantity; }}
> > S skickas bara f lten ver vilket r utm rkt n r jag p andra sidan > > kan f in datan i samma entitet. (l s mer h r fungerar efter .NET 3.5 > > SP1 > >http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/5... > > , lite l ngre ner p sidan finns en summary det r alternativ 2 jag > > syftar p d r man inte beh ver anv nda sig av attributes)
> > Men vid anv ndning av Silverlight s fungerar inte Serializeable > > p.g.a. d ligt st d av reflection.
> > Men s g t.ex. h r att _quantity bara g r att ndra med en metod p.g.a. > > olika kontroller eller what ever dvs man har ingen set property f r > > den.
> > S min grundfr ga hur f r jag samma resultat som tidigare med DTO:er > > utan att skr pa ner min dom nmodell f r mycket? > > r det en extra konstruktor p mitt objekt som tar emot DTO:n och > > s tter v rdena p sig sj lv och en metod som retunerar ungef r s som > > ISerializeable interfacet fungerar? > > Eller finns det trevligare l sningar?
> > On 23 Jan, 12:23, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: > >> Fast jag tror inte riktigt det jag f rs kte f rklara gick fram, s jag > >> f rs ker igen.
> >> Du kan absolut dela ditt BE library mellan klient och server om du vill, > >> ger du b da sidorna s r det ok. Men i kommunikationen mellan klient > >> och > >> server r det inte BE objekten optimalt att serializera / deserializera > >> utan > >> en b ttre strategi r att designa service-gr nssnitt som r > >> specialiserade > >> f r exakt den operation du vill utf ra. Det inneb r att man oftast m r > >> b st > >> av att skapa separata datakontrakt som r optimerade f r just > >> kommunikation > >> mellan server och klient och inte n dv ndigtvis optimerade f r att f nga > >> dom nen. Just ditt scenario visar ju dessutom p behovet, inget r privat > >> i > >> xml, vilket r det som skickas ver tr den, men du vill d lja det > >> faktumet i > >> din dom nmodell.
> >> S tipset, l sningen och rekommendationen r att skapa s rskilda DTO'er > >> som > >> r specialdesignade f r de operationer du vill utf ra. Om du dessutom > >> l gger > >> till Fredriks rekommendation om att du skall ha en presentationsmodell i > >> SL > >> och inte den riktiga dom nmodellen som ist llet borde bo bara p backend, > >> s > >> blir rekommendationen tre olika modeller. En p backend, en f r > >> wcf-gr nsnitten och en f r frontend.
> >> Att man vill ha en p frontend som fredrik f resl r, har m nga f rdelar, > >> men de tv som jag brukar lyfta fram r att man f r det f rsta inte kan > >> veta > >> vilka funktioner i en dom nmodell som r t nkta att anv ndas p frontend > >> eller backend (du kommer ju t dem p b da st llena) och f r det andra s > >> r > >> ju presentationen av modellen v ldigt ofta skilt fr n att jobba med > >> aff rslogik i modellen, det r ju tv olika syften.
> >> Sen r det ju ocks s att du kan ha privata medlemmar p backend som du > >> exponerar via datamember attributet, men SL kr ver att de r publika p > >> frontend. Men det visste du s klart redan :)
> >> > Det r precis detta jag vill uppn och som jag kan uppn p ett enkelt > >> > s tt, problemet r bara att vid verskickandet WCF till Silverlight s > >> > finns det en begr nsning som inte kan deserializera eller serialisera > >> > ner objekt med privata listor och datatyper eftersom de beh ver get; > >> > set; och get set p allting vill jag inte ha i en dom nmodell som jag > >> > g rna skulle vilja dela mellan klient och servicelayer. Eftersom jag > >> > som sagt inte vill fr ga min service r kna ut totalpriset av min order > >> > varje g ng jag ndrar ett v rde p en orderrad eller l gger till > >> > n got.Utan h r vill jag kunna arbeta klart med ordern p klienten utan > >> > att fr ga servern om information hela tiden.
> >> > On 22 Jan, 16:51, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: > >> > > Jo, det r en vanlig och riktigt bra l sning.
> >> > > Repositoryt bryr ju sig egentligen inte om vad "storage" r f r n got > >> > utan > >> > > r bara intresserat av att f ut BE objekt fr n n gon annastans. > >> > > Oftast > >> > > brukar det h r inte vara just en "Repository" dock utan mer en > >> > > "proxy" > >> > som > >> > > anv nder en translator p insidan.
> >> > > > Jag kan egentligen p tok f r lite b de om Silverlight och > >> > problematiken > >> > > > ni diskuterar f r att l gga mig i, men...
> >> > > > Kan man inte likst lla kommunikationen i WCF med den mot en > >> > > > databas? > >> > Dvs, > >> > > > kan man inte ha ett Repository p klienten som arbetar mot WCF p > >> > > > samma > >> > s tt > >> > > > som man jobbar mot sin ORM. Skicka ver riktiga dom nobjekt > >> > > > inklusive > >> > BL > >> > > > ist llet f r dumma DTO:er. Och kanske ven bygga en identity map p > >> > > > klientsidan som garanterar att endast en instans finns av varje > >> > entitet.
Om du vill exponera ut dina domain entiteter ver n tet s ta en titt p WCF RIA Services, l ter som det passar dig perfekt :)
Jag har under m nga r byggt stora enterprisel sningar s som B2B, fraktsystem etc. Har aldrig uppfattat mappningen som ett underh llsproblem. Jag har iofs inte varit med i dom projekt du har varit och r med i, d r problemet verkligen har uppst tt med underh ll av mappning efter produktion. Men jag vill nd p st att du "kan" ven f underh llsproblem (tom med v rre i vissa scenarion) utan DTOer, pga att du skickar dina entiteter hela v gen upp till presentationslagret d r mappningen mellan entiten och vyn sker.
1) T nk dig f ljande. Du har en entitet med FirstName och LastName. Du skickar denna till vyn, du ska i vyn visa FullName. S du ser till s vyn tar FirstName och LastName och sl r ihop dom. Dett sker p flertal vyer och heltpl tsligt s har du duplicerat kod p flera st llen n ett.
2) Du m ste nu i dom nmodellen l gga till MiddleName, s du g r det. Vyerna m ste nu ven ta med MiddleName, s dina FullName ska uppdateras. Du f r nu g in p flera vyer och g ra denna ndring.
3) Av n gon annledning s ska nu LastName inte visas p vyn, utan bara FirstName och MiddleName. Nu m ste du g in i alla dina vyer och ndra FullName till att ta FirstName och MiddleName.
Om du skapade en DTO ist llet s har den egenskapen FullName. I din mappning p server-sidan kan du se till att FullName inneh ller FirstName och LastName. Du har nu inte duplicerat koden p flera st llen och alla vyer g r nu mot DTOns FullName. Sedan n r ndring sker i dom nmodellen som i steg 2 och 3, s har du ett st lle att ndra och beh ver inte g in i dina vyer.
Ett annat scenario:
1) Du har en DTO som visar FullName och LastName, din dom n entitet har FullName och LastName. Nu s ndras dom nmodellen s att LastName byter namn till SureName. Nu m ste du in i mappningen och ndra. I detta fall beh ver du inte ndra i vyn och kan l ta din DTO ha egenskapen LastName f r den bryr sig inte om namnbytet (om det inte r ett m ste, d f r du mer jobb).
2) Om du nu skikade din dom nmodell till Vyn, och denna f r ndring sker, s m ste du uppdatera alla vyer som mappar mot LastName till att mappa mot SureName, det r mer jobb n att ndra en liten mappning p server-sidan.
Ett annat scenario:
1) Du har en DTO som visar FullName och LastName. Din dom nmodell har samma egenskaper. Nu s tillkommer MiddleName i dom nmodellen. Dina vyer ska nu visa MiddelName ocks . S du m ste uppdatera alla vyer att visa MiddleName och sedan se till att uppdatera din mappning mellan dom nmodellen och DTOn, h r kommer du tyv rr f br nna n gra extra kalorier ;) Men med AutoMapper s kan du slippa bry dig om denna mappning, men du m ste ndra din DTO och l gga till MiddleName.
Som du ser s m ngden underh ll har med vad f r typ av ndring som sker oftast. Utan DTOer kan inneb rar mer underh ll, men kan ven med DTOer inneb ra mer underh ll. Det du kan garanterat veta, r att du med DTOer begr nsar risken f r prestandaproblem, samt f retag som k r in the cloud kan ven spara tusentalskornor pga att de inte beh ver betala f r on dig m ngd data. r det en intranetl sning som ligger lokalt, s skulle jag kanske inte bry mig om DTOer lika mycket som om det r en publik eller enterprisel sning.
Mvh Fredrik Norm n
-------------------------------------------------- From: "Niclas Pehrsson" <pehrs...@gmail.com> Sent: Sunday, January 24, 2010 12:24 AM To: "Sweden ALT.NET" <sweden-altnet@googlegroups.com> Subject: Re: Silverlight, DTO, DDD
> Jo jag k nner till hans lag hehe.. och dom tv saker som listas mot > benefits anser jag inte v ga ver det jobbiga med att underh lla > mappningen. > Jo s l ngt r jag med hur du g r det till DTO problemet r hur du > f rvandlar DTO'n till entitet sedan p klienten. > Om du l sten l nken jag skickade med ovan s beh ver man inte skapa > n gon DTO eller tillbaka det sker i bakgrunden. > S jag undrar om det finns n got liknande tillv gag ngs tt f r > Silverlight d det r sp rrat p.g.a. sandboxen som om jlig r > anv ndandet av [Serializeable].
> On 23 Jan, 19:58, Fredrik Norm n <fnor...@hotmail.com> wrote: >> I WCF skapar du ett datakontrakt.. detta r din DTO
>> I din WCF Service s mappar du din Entites mot detta datakontrakt innan du >> returnerar det..
>> Tex:
>> public IEnumerable<MemberDto> GetMembers() >> { >> var members = _memberRepository.GetAll();
>> Lite mer info om DTO: >> "My First Law of Distributed Object Design: Don't distribute your >> objects" - >> Martin Fowler (P of EAA)
>> "Objects have been around for a while, and sometimes it seems that ever >> since they were created, folks have wanted to distribute them. However, >> distribution of objects, or indeed of anything else, has a lot more >> pitfalls >> than many people realize, especially when they're under the influence of >> vendors' cozy brochures." - Martin Fowler >> (http://www.ddj.com/architect/184414966)
>> Instead of sharing a single entity implementation between the mid-tier >> and >> the client, we can create a custom object (DTO) that is only used for >> passing data over the wire. Most entities in our domain model is not >> often >> designed with distribution in mind. Using DTO have two main benefits >> regarding to Daniel Simmons (Architect on the Entity Framework team at >> Microsoft):
>> "It isolates your service contract from implementation issues on the >> mid-tier and the client, allowing that contract to remain stable even if >> the >> implementation on the tiers changes, and it allows you to control what >> data >> flows over the wire. Therefore, you can avoid sending unnecessary data >> (or >> data the client is not allowed to access) or reshape the data to make it >> more convenient for the service. Generally, the service contract is >> designed >> with the client scenarios in mind so that the data can be reshaped >> between >> the mid-tier entities and the DTOs (maybe by combining multiple entities >> into one DTO and skipping properties not needed on the client), while the >> DTOs can be used directly on the client.
>> These benefits, however, come at the price of having to create and >> maintain >> one or two more layers of objects and mapping." - Daniel Simmons >> (Building >> N-Tier Apps with EF4)
>> > Ja det jag r ute efter r att kunna dela mina BE p b da sidor, d r >> > jag anv nder mig av ViewModel's p Silverlight f r presentation. >> > Min fr ga var just det jag skrev ovan, hur jag p ett smidigt s tt kan >> > skicka ver datan och omvandla Entitet till DTO p servicen och >> > tv rtom p klienten. >> > Som jag beskriver i mitt f rsta inl gg s g r detta utm rkt utan att >> > ens beh va t nka p det i en WPF & WCF milj om man s tter >> > [Serializeable] p objektet >> > s klarar WCF av att bara serializera ner mina f lt som ligger p >> > objektet och sedan deserializera det p klienten. Dvs vid ett objekt >> > som ser ut f ljande.
>> > public decimal TotalPrice { get { return _unitPrice * _quantity; }}
>> > S skickas bara f lten ver vilket r utm rkt n r jag p andra sidan >> > kan f in datan i samma entitet. (l s mer h r fungerar efter .NET 3.5 >> > SP1 >> >http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/5... >> > , lite l ngre ner p sidan finns en summary det r alternativ 2 jag >> > syftar p d r man inte beh ver anv nda sig av attributes)
>> > Men vid anv ndning av Silverlight s fungerar inte Serializeable >> > p.g.a. d ligt st d av reflection.
>> > Men s g t.ex. h r att _quantity bara g r att ndra med en metod p.g.a. >> > olika kontroller eller what ever dvs man har ingen set property f r >> > den.
>> > S min grundfr ga hur f r jag samma resultat som tidigare med DTO:er >> > utan att skr pa ner min dom nmodell f r mycket? >> > r det en extra konstruktor p mitt objekt som tar emot DTO:n och >> > s tter v rdena p sig sj lv och en metod som retunerar ungef r s som >> > ISerializeable interfacet fungerar? >> > Eller finns det trevligare l sningar?
>> > On 23 Jan, 12:23, Patrik Lowendahl <patrik.lowend...@gmail.com> wrote: >> >> Fast jag tror inte riktigt det jag f rs kte f rklara gick fram, s jag >> >> f rs ker igen.
>> >> Du kan absolut dela ditt BE library mellan klient och server om du >> >> vill, >> >> ger du b da sidorna s r det ok. Men i kommunikationen mellan klient >> >> och >> >> server r det inte BE objekten optimalt att serializera / deserializera >> >> utan >> >> en b ttre strategi r att designa service-gr nssnitt som r >> >> specialiserade >> >> f r exakt den operation du vill utf ra. Det inneb r att man oftast m r >> >> b st >> >> av att skapa separata datakontrakt som r optimerade f r just >> >> kommunikation >> >> mellan server och klient
Nja jag tror inte jag kommer att ha det problemet. Logiken för att sätta ihop first name och lastname ligger på entiteten t.ex. en Name klass som enteteten som innehåller namnet har kan se ut följande.
public class Name { public string First { get; set; } public string Last { get; set; }
public string Full { get { return string.format("{0} {1}", First, Last); }
}
Jag knyter mina entiteter mot ViewModels så byts ett namn i min DDD entitet så bör den även med ett bra refaktoreringsverktyg även bytas i min viewmodel som håller korrekt bindning mot viewn i Silverlight.
Mina huvudproblem med DTO'er är att jag måste lägga all logik på servern vilket jag inte vill, jag vill inte belasta servern med att behöva räkna om t.ex. fakturans totalpris vid minsta ändring på fakturan utan låta vyn kunna göra detta.. Därför vill jag ha shared libaries som sagt. men detta går inte då Silverlight inte stödjer Serializeable så att man kan inte vid överskickandet använda sig av privata properties eller privata fält som inte exposas av klassens kontrakt. Så min fråga finns det några sjysta lösningar på det problemet. automapper går bort då den inte kan sätta privata fält som kanske inte exposas via klassens publika kontrakt. (obs jag vill absolut inte använda mig av DataContract, DataMember attribut i domänmodellen). Kolla länken: http://www.google.com/url?sa=D&q=http://www.pluralsight.com/community... på alternativ 2 i summaryn det är vad jag vill åstakomma.
On 24 Jan, 09:31, Fredrik Normén <fnor...@hotmail.com> wrote:
> Om du vill exponera ut dina domain entiteter ver n tet s ta en titt p WCF > RIA Services, l ter som det passar dig perfekt :)
> Jag har under m nga r byggt stora enterprisel sningar s som B2B, > fraktsystem etc. Har aldrig uppfattat mappningen som ett underh llsproblem. > Jag har iofs inte varit med i dom projekt du har varit och r med i, d r > problemet verkligen har uppst tt med underh ll av mappning efter produktion. > Men jag vill nd p st att du "kan" ven f underh llsproblem (tom med > v rre i vissa scenarion) utan DTOer, pga att du skickar dina entiteter hela > v gen upp till presentationslagret d r mappningen mellan entiten och vyn > sker.
> 1) T nk dig f ljande. Du har en entitet med FirstName och LastName. Du > skickar denna till vyn, du ska i vyn visa FullName. S du ser till s vyn > tar FirstName och LastName och sl r ihop dom. Dett sker p flertal vyer och > heltpl tsligt s har du duplicerat kod p flera st llen n ett.
> 2) Du m ste nu i dom nmodellen l gga till MiddleName, s du g r det. Vyerna > m ste nu ven ta med MiddleName, s dina FullName ska uppdateras. Du f r nu > g in p flera vyer och g ra denna ndring.
> 3) Av n gon annledning s ska nu LastName inte visas p vyn, utan bara > FirstName och MiddleName. Nu m ste du g in i alla dina vyer och ndra > FullName till att ta FirstName och MiddleName.
> Om du skapade en DTO ist llet s har den egenskapen FullName. I din mappning > p server-sidan kan du se till att FullName inneh ller FirstName och > LastName. Du har nu inte duplicerat koden p flera st llen och alla vyer g r > nu mot DTOns FullName. Sedan n r ndring sker i dom nmodellen som i steg 2 > och 3, s har du ett st lle att ndra och beh ver inte g in i dina vyer.
> Ett annat scenario:
> 1) Du har en DTO som visar FullName och LastName, din dom n entitet har > FullName och LastName. Nu s ndras dom nmodellen s att LastName byter namn > till SureName. Nu m ste du in i mappningen och ndra. I detta fall beh ver > du inte ndra i vyn och kan l ta din DTO ha egenskapen LastName f r den bryr > sig inte om namnbytet (om det inte r ett m ste, d f r du mer jobb).
> 2) Om du nu skikade din dom nmodell till Vyn, och denna f r ndring sker, s > m ste du uppdatera alla vyer som mappar mot LastName till att mappa mot > SureName, det r mer jobb n att ndra en liten mappning p server-sidan.
> Ett annat scenario:
> 1) Du har en DTO som visar FullName och LastName. Din dom nmodell har samma > egenskaper. Nu s tillkommer MiddleName i dom nmodellen. Dina vyer ska nu > visa MiddelName ocks . S du m ste uppdatera alla vyer att visa MiddleName > och sedan se till att uppdatera din mappning mellan dom nmodellen och DTOn, > h r kommer du tyv rr f br nna n gra extra kalorier ;) Men med AutoMapper s > kan du slippa bry dig om denna mappning, men du m ste ndra din DTO och > l gga till MiddleName.
> Som du ser s m ngden underh ll har med vad f r typ av ndring som sker > oftast. Utan DTOer kan inneb rar mer underh ll, men kan ven med DTOer > inneb ra mer underh ll. Det du kan garanterat veta, r att du med DTOer > begr nsar risken f r prestandaproblem, samt f retag som k r in the cloud kan > ven spara tusentalskornor pga att de inte beh ver betala f r on dig m ngd > data. r det en intranetl sning som ligger lokalt, s skulle jag kanske inte > bry mig om DTOer lika mycket som om det r en publik eller > enterprisel sning.
> Mvh Fredrik Norm n
> -------------------------------------------------- > From: "Niclas Pehrsson" <pehrs...@gmail.com> > Sent: Sunday, January 24, 2010 12:24 AM > To: "Sweden ALT.NET" <sweden-altnet@googlegroups.com> > Subject: Re: Silverlight, DTO, DDD
> > Jo jag k nner till hans lag hehe.. och dom tv saker som listas mot > > benefits anser jag inte v ga ver det jobbiga med att underh lla > > mappningen. > > Jo s l ngt r jag med hur du g r det till DTO problemet r hur du > > f rvandlar DTO'n till entitet sedan p klienten. > > Om du l sten l nken jag skickade med ovan s beh ver man inte skapa > > n gon DTO eller tillbaka det sker i bakgrunden. > > S jag undrar om det finns n got liknande tillv gag ngs tt f r > > Silverlight d det r sp rrat p.g.a. sandboxen som om jlig r > > anv ndandet av [Serializeable].
> > On 23 Jan, 19:58, Fredrik Norm n <fnor...@hotmail.com> wrote: > >> I WCF skapar du ett datakontrakt.. detta r din DTO
> >> I din WCF Service s mappar du din Entites mot detta datakontrakt innan du > >> returnerar det..
> >> Tex:
> >> public IEnumerable<MemberDto> GetMembers() > >> { > >> var members = _memberRepository.GetAll();
> >> Lite mer info om DTO: > >> "My First Law of Distributed Object Design: Don't distribute your > >> objects" - > >> Martin Fowler (P of EAA)
> >> "Objects have been around for a while, and sometimes it seems that ever > >> since they were created, folks have wanted to distribute them. However, > >> distribution of objects, or indeed of anything else, has a lot more > >> pitfalls > >> than many people realize, especially when they're under the influence of > >> vendors' cozy brochures." - Martin Fowler > >> (http://www.ddj.com/architect/184414966)
> >> Instead of sharing a single entity implementation between the mid-tier > >> and > >> the client, we can create a custom object (DTO) that is only used for > >> passing data over the wire. Most entities in our domain model is not > >> often > >> designed with distribution in mind. Using DTO have two main benefits > >> regarding to Daniel Simmons (Architect on the Entity Framework team at > >> Microsoft):
> >> "It isolates your service contract from implementation issues on the > >> mid-tier and the client, allowing that contract to remain stable even if > >> the > >> implementation on the tiers changes, and it allows you to control what > >> data > >> flows over the wire. Therefore, you can avoid sending unnecessary data > >> (or > >> data the client is not allowed to access) or reshape the data to make it > >> more convenient for the service. Generally, the service contract is > >> designed > >> with the client scenarios in mind so that the data can be reshaped > >> between > >> the mid-tier entities and the DTOs (maybe by combining multiple entities > >> into one DTO and skipping properties not needed on the client), while the > >> DTOs can be used directly on the client.
> >> These benefits, however, come at the price of having to create and > >> maintain > >> one or two more layers of objects and mapping." - Daniel Simmons > >> (Building > >> N-Tier Apps with EF4)
> >> > Ja det jag r ute efter r att kunna dela mina BE p b da sidor, d r > >> > jag anv nder mig av ViewModel's p Silverlight f r presentation. > >> > Min fr ga var just det jag skrev ovan, hur jag p ett smidigt s tt kan > >> > skicka ver datan och omvandla Entitet till DTO p servicen och > >> > tv rtom p klienten. > >> > Som jag beskriver i mitt f rsta inl gg s g r detta utm rkt utan att > >> > ens beh va t nka p det i en WPF & WCF milj om man s tter > >> > [Serializeable] p objektet > >> > s klarar WCF av att bara serializera ner mina f lt som ligger p > >> > objektet och sedan deserializera det p klienten. Dvs vid ett objekt > >> > som ser ut f ljande.
Du vill ju inte ha Full i dom nmodellen om det inte kr vs.. plottra dom nen pga vyn, inte att f redra.. och helt on digt.. dom nmodellen designas utan en vy "in mind".
Men du beh ver inte l gg all logik p servern f r att du k r med DTO, DTO b r bara p datan som ska skickas mellan server och klient. Du kan r kna ut priset i vyn, det r det du har en ViewModel till..
SLs serialisering har get och set publika, s du f r leva med det.
Ett alternativ r att du tar en titt p WCF RIA Services som jag n mnde innan, d r kan du exponera dina entiteter och du kan ven ha logic shared.
Mvh Fredrik N
-------------------------------------------------- From: "Niclas Pehrsson" <pehrs...@gmail.com> Sent: Sunday, January 24, 2010 10:32 AM To: "Sweden ALT.NET" <sweden-altnet@googlegroups.com> Subject: Re: Silverlight, DTO, DDD
> Nja jag tror inte jag kommer att ha det problemet. > Logiken f r att s tta ihop first name och lastname ligger p entiteten > t.ex. en Name klass som enteteten som inneh ller namnet har kan se ut > f ljande.
> public class Name > { > public string First { get; set; } > public string Last { get; set; }
> public string Full { get { return string.format("{0} {1}", First, > Last); } > }
> Jag knyter mina entiteter mot ViewModels s byts ett namn i min DDD > entitet s b r den ven med ett bra refaktoreringsverktyg ven bytas i > min viewmodel som h ller korrekt bindning mot viewn i Silverlight.
> Mina huvudproblem med DTO'er r att jag m ste l gga all logik p > servern vilket jag inte vill, jag vill inte belasta servern med att > beh va r kna om t.ex. fakturans totalpris vid minsta ndring p > fakturan utan l ta vyn kunna g ra detta.. D rf r vill jag ha shared > libaries som sagt. men detta g r inte d Silverlight inte st djer > Serializeable s att man kan inte vid verskickandet anv nda sig av > privata properties eller privata f lt som inte exposas av klassens > kontrakt. S min fr ga finns det n gra sjysta l sningar p det > problemet. automapper g r bort d den inte kan s tta privata f lt > som kanske inte exposas via klassens publika kontrakt. (obs jag vill > absolut inte anv nda mig av DataContract, DataMember attribut i > dom nmodellen). Kolla l nken: > http://www.google.com/url?sa=D&q=http://www.pluralsight.com/community... > p alternativ 2 i summaryn det r vad jag vill stakomma.
> On 24 Jan, 09:31, Fredrik Norm n <fnor...@hotmail.com> wrote: >> Om du vill exponera ut dina domain entiteter ver n tet s ta en titt p WCF >> RIA Services, l ter som det passar dig perfekt :)
>> Jag har under m nga r byggt stora enterprisel sningar s som B2B, >> fraktsystem etc. Har aldrig uppfattat mappningen som ett underh >> llsproblem. >> Jag har iofs inte varit med i dom projekt du har varit och r med i, d r >> problemet verkligen har uppst tt med underh ll av mappning efter >> produktion. >> Men jag vill nd p st att du "kan" ven f underh llsproblem (tom med >> v rre i vissa scenarion) utan DTOer, pga att du skickar dina entiteter >> hela >> v gen upp till presentationslagret d r mappningen mellan entiten och vyn >> sker.
>> 1) T nk dig f ljande. Du har en entitet med FirstName och LastName. Du >> skickar denna till vyn, du ska i vyn visa FullName. S du ser till s vyn >> tar FirstName och LastName och sl r ihop dom. Dett sker p flertal vyer >> och >> heltpl tsligt s har du duplicerat kod p flera st llen n ett.
>> 2) Du m ste nu i dom nmodellen l gga till MiddleName, s du g r det. >> Vyerna >> m ste nu ven ta med MiddleName, s dina FullName ska uppdateras. Du f r nu >> g in p flera vyer och g ra denna ndring.
>> 3) Av n gon annledning s ska nu LastName inte visas p vyn, utan bara >> FirstName och MiddleName. Nu m ste du g in i alla dina vyer och ndra >> FullName till att ta FirstName och MiddleName.
>> Om du skapade en DTO ist llet s har den egenskapen FullName. I din >> mappning >> p server-sidan kan du se till att FullName inneh ller FirstName och >> LastName. Du har nu inte duplicerat koden p flera st llen och alla vyer g >> r >> nu mot DTOns FullName. Sedan n r ndring sker i dom nmodellen som i steg 2 >> och 3, s har du ett st lle att ndra och beh ver inte g in i dina vyer.
>> Ett annat scenario:
>> 1) Du har en DTO som visar FullName och LastName, din dom n entitet har >> FullName och LastName. Nu s ndras dom nmodellen s att LastName byter namn >> till SureName. Nu m ste du in i mappningen och ndra. I detta fall beh ver >> du inte ndra i vyn och kan l ta din DTO ha egenskapen LastName f r den >> bryr >> sig inte om namnbytet (om det inte r ett m ste, d f r du mer jobb).
>> 2) Om du nu skikade din dom nmodell till Vyn, och denna f r ndring sker, >> s >> m ste du uppdatera alla vyer som mappar mot LastName till att mappa mot >> SureName, det r mer jobb n att ndra en liten mappning p server-sidan.
>> Ett annat scenario:
>> 1) Du har en DTO som visar FullName och LastName. Din dom nmodell har >> samma >> egenskaper. Nu s tillkommer MiddleName i dom nmodellen. Dina vyer ska nu >> visa MiddelName ocks . S du m ste uppdatera alla vyer att visa MiddleName >> och sedan se till att uppdatera din mappning mellan dom nmodellen och >> DTOn, >> h r kommer du tyv rr f br nna n gra extra kalorier ;) Men med AutoMapper >> s >> kan du slippa bry dig om denna mappning, men du m ste ndra din DTO och >> l gga till MiddleName.
>> Som du ser s m ngden underh ll har med vad f r typ av ndring som sker >> oftast. Utan DTOer kan inneb rar mer underh ll, men kan ven med DTOer >> inneb ra mer underh ll. Det du kan garanterat veta, r att du med DTOer >> begr nsar risken f r prestandaproblem, samt f retag som k r in the cloud >> kan >> ven spara tusentalskornor pga att de inte beh ver betala f r on dig m ngd >> data. r det en intranetl sning som ligger lokalt, s skulle jag kanske >> inte >> bry mig om DTOer lika mycket som om det r en publik eller >> enterprisel sning.
>> Mvh Fredrik Norm n
>> -------------------------------------------------- >> From: "Niclas Pehrsson" <pehrs...@gmail.com> >> Sent: Sunday, January 24, 2010 12:24 AM >> To: "Sweden ALT.NET" <sweden-altnet@googlegroups.com> >> Subject: Re: Silverlight, DTO, DDD
>> > Jo jag k nner till hans lag hehe.. och dom tv saker som listas mot >> > benefits anser jag inte v ga ver det jobbiga med att underh lla >> > mappningen. >> > Jo s l ngt r jag med hur du g r det till DTO problemet r hur du >> > f rvandlar DTO'n till entitet sedan p klienten. >> > Om du l sten l nken jag skickade med ovan s beh ver man inte skapa >> > n gon DTO eller tillbaka det sker i bakgrunden. >> > S jag undrar om det finns n got liknande tillv gag ngs tt f r >> > Silverlight d det r sp rrat p.g.a. sandboxen som om jlig r >> > anv ndandet av [Serializeable].
>> > On 23 Jan, 19:58, Fredrik Norm n <fnor...@hotmail.com> wrote: >> >> I WCF skapar du ett datakontrakt.. detta r din DTO
>> >> I din WCF Service s mappar du din Entites mot detta datakontrakt innan >> >> du >> >> returnerar det..
>> >> Tex:
>> >> public IEnumerable<MemberDto> GetMembers() >> >> { >> >> var members = _memberRepository.GetAll();
>> >> Lite mer info om DTO: >> >> "My First Law of Distributed Object Design: Don't distribute your >> >> objects" - >> >> Martin Fowler (P of EAA)
>> >> "Objects have been around for a while, and sometimes it seems that >> >> ever >> >> since they were created, folks have wanted to distribute them. >> >> However, >> >> distribution of objects, or indeed of anything else, has a lot more >> >> pitfalls >> >> than many people realize, especially when they're under the influence >> >> of >> >> vendors' cozy brochures." - Martin Fowler >> >> (http://www.ddj.com/architect/184414966)
>> >> Instead of sharing a single entity implementation between the mid-tier >> >> and >> >> the client, we can create a custom object (DTO) that is only used for >> >> passing data over the wire. Most entities in our domain model is not >> >> often >> >> designed with distribution in mind. Using DTO have two main benefits >> >> regarding to Daniel Simmons (Architect on the Entity Framework team at >> >> Microsoft):
>> >> "It isolates your service contract from implementation issues on the >> >> mid-tier and the client, allowing that contract to remain stable even >> >> if >> >> the >> >> implementation on the tiers changes, and it allows you to control what >> >> data >> >> flows over the wire. Therefore, you can avoid sending unnecessary data >> >> (or >> >> data the client is not allowed to access) or reshape the data to make >> >> it >> >> more convenient for the service. Generally, the service contract is >> >> designed >> >> with the client scenarios in mind so that the data can be reshaped >> >> between >> >> the mid-tier entities and the DTOs (maybe by combining multiple >> >> entities >> >> into one DTO and skipping properties not needed on the client), while >> >> the >> >> DTOs can be used directly on the client.
>> >> These benefits, however, come at the price of having to create and >> >> maintain >> >> one or two more layers of objects and mapping." - Daniel Simmons >> >> (Building >> >> N-Tier Apps with EF4)
|
