headers
Hendry Luk | 1 Jun 06:41
Picon

Re: Re: When using asp.net MVC...



For command, the main reasons to use services are validation and backend systems.
As for query, backend system is still often a reason I need services.

The problem I have in my project is that most of the entity properties (e.g. Subscription) comes from backend services like billing-engine or TML rather than database. Only minimal subset of information is stored in database, but to get a complete state of the domain entity, simple repository lookup is not sufficient.

We put it behind a service that calls repository as well as remote call to billing engine and TML to populate the rest of subscription detail, but that opens up another can of worm:
1. It doesnt feel right to have the repository to load/persist only half of the entity state, leaving the other half unpopulated which clearly breaks object invariant.
2. No one ever says that repository has to be for database only. Why do we need Service to access remote backend? Repository is a layer that handles entity's states and lifecycle. Any thought about whether I should encapsulate lots of remote infrastructure behind repository (instead of services in application layer?).
3. Loading all entities information from all backend systems is not efficient. 99% of the time we don't need customer's address. Neither do we need how many accounts/susbcriptions they have, what plan they're on, or even if he's still active or not. We need some kind of lazy load mechanism really, but instead what we have is bunch of Service overload like:
getCustomerWithFullDetail()
getCustomerAndAllActiveSusbcrtipionWithoutAddressInfo()
getCustomerWithBlaBlaAndBla()

Thoughts?

On Mon, Jun 1, 2009 at 6:45 AM, Gareth Down <g <at> garethdown.com> wrote:


Hi Jeff

Thanks very much for your reply. Are you saying you'd do things differently if the operation was a command?

Does anyone else have any thoughts on this? Jeff's the only person who's replied.

Gareth



2009/5/30 Jeff Gillin <jeffro3377 <at> yahoo.com>



I would say that for this particular concern you are showing, you don't need a service layer because you are just getting an item to display. When thinking in terms of command query separation, this is just a query and is perfectly OK to retrieve from your controller or presenter.


--- In domaindrivendesign <at> yahoogroups.com, Gareth Down <g <at> ...> wrote:
>
> Hi
>
> I am using ASP.NET MVC for a products I'm working on. I was just wondering
> what the DDD community thought about where the kind of "entry point" code
> should go, i.e. the code that accesses the repositories and actually brings
> everything together.
>
> Quite a few people say that you shouldn't really have very much in your
> controllers at all and they should really just field requests to a so called
> 'service' layer, for example:
>
> http://stackoverflow.com/questions/338816/should-controllers-in-an-asp-net-mvc-web-app-call-repositories-services-or-both
>
> I've started working for a new company and taken on a project where the
> previous developer has a 'service' for each of the entities, eg if there was
> a Product object there would be a ProductService with a few methods like
> GetProduct(int id) etc and basically whenever there's a call to a
> controller, it gets fielded to a service in the same way the person has
> suggested in that stackoverflow answer.
>
> The problem is I think these people are using the word service in a
> different way to the way DDD people talk about services. I think they're
> using the term in the way DDD people talk about repositories. For example
> the product I've inherited there are methods similar to
> GetAllVisibleProducts(), GetAllProducts(), DeleteProduct(id) etc, etc. I
> would say these were repository operations personally.
>
> Eric Evans says, as I'm sure you're all aware "A service tends to be named
> for an activity, rather than an entity - a verb rather than a noun".
>
> Therefore this approach seems wrong to me.
>
> Personally I can't see the problem of having the controller interact with
> the model directly.
>
> For example, I have this method: (I've stripped out a extra code that checks
> for a null entry etc and a security check etc, but you get the idea)
>
> public ActionResult EditEntry(int id, int subscriptionId)
> {
> var subscription =
> subscriptionRepository.FindSubscription(subscriptionId);
> var entry = subscription.Entries.FirstOrDefault(x => x.Id == id);
> return View(ViewModelOf(entry));
> }
>
> Now I can't see what is wrong with that? The user makes a request to edit a
> subscription entry, the controller asks the repository for the subscription,
> finds the entry and returns the View to the user.
>
> Why should I put a service there, aren't I just adding an extra layer for no
> reason? One reason people cite is code re-use, e.g. if you want to use the
> same code and put a different user interface there. But what if I know
> that's never going to happen? I know this app will never have a windows
> forms interface for example.
>
> Another example I've got is this: (note the ActiveUser property calls a user
> repository)
>
> public ActionResult Index()
> {
> return View(ActiveUser.Subscriptions);
> }
>
> That's really simple, is there any reason to add a whole other layer which
> does the same thing? To me it would mean more code to write more
> dependencies to hook up and more stuff to test.
>
> I'd really like to know if anyone has any thoughts about this or can point
> out anything I'm missing or not thinking of.
>
> Any responses would be much appreciated.
>
> Thanks
>
> Gareth
>





__._,_.___


Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 12 comments |
headers
Justin Daubenmire | 1 Jun 07:26
Picon
Favicon

repository and infrastructure return values



All,
 
A silly question, but I was just curious what people return from the infrastructure when performing an insert or delete operation to a database?
 
For example, do you return an int indicating 1 for success 0 for failure? Do you return an exception? Do you not return anything from your insert/delete/update operations?
 
What do you typically have your repositories return for an add/update/delete operation from your methods?
 
Wondering how folks track errors or problems in these layers and I am wondering what you do with the errors/messages?
 
Thanks!
 

Regards,
Justin
 


__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 5 comments |
headers
Joey Samonte | 1 Jun 07:33
Picon
Favicon
Gravatar

Re: repository and infrastructure return values



From my understanding, a method should throw an exception if that method can't do what it says it can...

From: Justin Daubenmire <jdaubenm <at> yahoo.com>
To: domaindrivendesign <at> yahoogroups.com
Sent: Monday, June 1, 2009 1:26:06 PM
Subject: [domaindrivendesign] repository and infrastructure return values

All,
 
A silly question, but I was just curious what people return from the infrastructure when performing an insert or delete operation to a database?
 
For example, do you return an int indicating 1 for success 0 for failure? Do you return an exception? Do you not return anything from your insert/delete/ update operations?
 
What do you typically have your repositories return for an add/update/delete operation from your methods?
 
Wondering how folks track errors or problems in these layers and I am wondering what you do with the errors/messages?
 
Thanks!
 

Regards,
Justin
 



__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 0 comments |
headers
Eben Roux | 1 Jun 08:31
Picon

Re: repository and infrastructure return values

Hello Justin,

In my repositories I do not trap exceptions.  So 'action' methods (such as insert, delete) return void. 
Fetching methods return the aggregate / collection of aggregates.

Since all calls are made from a service layer --- currently using a Tasks extension that I stole from JP
Boodhoo :) --- all exceptions are trapped here and wrapped in a TaskResult.  The nice thing is that the
TaskResult contains both an ErrorMessages collection and ConfirmationMessages collection (or call
them what you want).  TaskResult.OK returns false if there are Error messages.  Confirmation messages can
also be sent back --- such as 'Your order has been placed as order number ON-100-01'.  So the
{Blah}Tasks.{Method} always returns a TaskResult.  I actually have a 'Value' property on a generic
overload for when I send back values (such as a retrieved aggregate).  So a TaskResult<IOrder> for instance.

Of course you can go ape and perform logging on these messages in the service layer (via some appropriate
class / provider / factory).

Regards,
Eben

--- In domaindrivendesign <at> yahoogroups.com, "Justin Daubenmire" <jdaubenm@...> wrote:
>
> All,
> 
> A silly question, but I was just curious what people return from the infrastructure when performing an
insert or delete operation to a database?
> 
> For example, do you return an int indicating 1 for success 0 for failure? Do you return an exception? Do you
not return anything from your insert/delete/update operations?
> 
> What do you typically have your repositories return for an add/update/delete operation from your methods?
> 
> Wondering how folks track errors or problems in these layers and I am wondering what you do with the errors/messages?
> 
> Thanks!
> 
> 
> Regards,
> Justin
>

------------------------------------
Permalink | Reply | 3 comments |
headers
Nuno Lopes | 1 Jun 09:45
Picon
Gravatar

Re: Re: When using asp.net MVC...



I use the rep not only to encapsulate the mapping to the database but also to other systems in complex environments such as yours. 

Nuno

On 2009/06/01, at 05:41, Hendry Luk <hendrymail <at> gmail.com> wrote:

For command, the main reasons to use services are validation and backend systems.
As for query, backend system is still often a reason I need services.

The problem I have in my project is that most of the entity properties (e.g. Subscription) comes from backend services like billing-engine or TML rather than database. Only minimal subset of information is stored in database, but to get a complete state of the domain entity, simple repository lookup is not sufficient.

We put it behind a service that calls repository as well as remote call to billing engine and TML to populate the rest of subscription detail, but that opens up another can of worm:
1. It doesnt feel right to have the repository to load/persist only half of the entity state, leaving the other half unpopulated which clearly breaks object invariant.
2. No one ever says that repository has to be for database only. Why do we need Service to access remote backend? Repository is a layer that handles entity's states and lifecycle. Any thought about whether I should encapsulate lots of remote infrastructure behind repository (instead of services in application layer?).
3. Loading all entities information from all backend systems is not efficient. 99% of the time we don't need customer's address. Neither do we need how many accounts/susbcriptions they have, what plan they're on, or even if he's still active or not. We need some kind of lazy load mechanism really, but instead what we have is bunch of Service overload like:
getCustomerWithFullDetail()
getCustomerAndAllActiveSusbcrtipionWithoutAddressInfo()
getCustomerWithBlaBlaAndBla()

Thoughts?

On Mon, Jun 1, 2009 at 6:45 AM, Gareth Down <g <at> garethdown.com> wrote:


Hi Jeff

Thanks very much for your reply. Are you saying you'd do things differently if the operation was a command?

Does anyone else have any thoughts on this? Jeff's the only person who's replied.

Gareth



2009/5/30 Jeff Gillin <jeffro3377 <at> yahoo.com>



I would say that for this particular concern you are showing, you don't need a service layer because you are just getting an item to display. When thinking in terms of command query separation, this is just a query and is perfectly OK to retrieve from your controller or presenter.


--- In domaindrivendesign <at> yahoogroups.com, Gareth Down <g <at> ...> wrote:
>
> Hi
>
> I am using ASP.NET MVC for a products I'm working on. I was just wondering
> what the DDD community thought about where the kind of "entry point" code
> should go, i.e. the code that accesses the repositories and actually brings
> everything together.
>
> Quite a few people say that you shouldn't really have very much in your
> controllers at all and they should really just field requests to a so called
> 'service' layer, for example:
>
> http://stackoverflow.com/questions/338816/should-controllers-in-an-asp-net-mvc-web-app-call-repositories-services-or-both
>
> I've started working for a new company and taken on a project where the
> previous developer has a 'service' for each of the entities, eg if there was
> a Product object there would be a ProductService with a few methods like
> GetProduct(int id) etc and basically whenever there's a call to a
> controller, it gets fielded to a service in the same way the person has
> suggested in that stackoverflow answer.
>
> The problem is I think these people are using the word service in a
> different way to the way DDD people talk about services. I think they're
> using the term in the way DDD people talk about repositories. For example
> the product I've inherited there are methods similar to
> GetAllVisibleProducts(), GetAllProducts(), DeleteProduct(id) etc, etc. I
> would say these were repository operations personally.
>
> Eric Evans says, as I'm sure you're all aware "A service tends to be named
> for an activity, rather than an entity - a verb rather than a noun".
>
> Therefore this approach seems wrong to me.
>
> Personally I can't see the problem of having the controller interact with
> the model directly.
>
> For example, I have this method: (I've stripped out a extra code that checks
> for a null entry etc and a security check etc, but you get the idea)
>
> public ActionResult EditEntry(int id, int subscriptionId)
> {
> var subscription =
> subscriptionRepository.FindSubscription(subscriptionId);
> var entry = subscription.Entries.FirstOrDefault(x => x.Id == id);
> return View(ViewModelOf(entry));
> }
>
> Now I can't see what is wrong with that? The user makes a request to edit a
> subscription entry, the controller asks the repository for the subscription,
> finds the entry and returns the View to the user.
>
> Why should I put a service there, aren't I just adding an extra layer for no
> reason? One reason people cite is code re-use, e.g. if you want to use the
> same code and put a different user interface there. But what if I know
> that's never going to happen? I know this app will never have a windows
> forms interface for example.
>
> Another example I've got is this: (note the ActiveUser property calls a user
> repository)
>
> public ActionResult Index()
> {
> return View(ActiveUser.Subscriptions);
> }
>
> That's really simple, is there any reason to add a whole other layer which
> does the same thing? To me it would mean more code to write more
> dependencies to hook up and more stuff to test.
>
> I'd really like to know if anyone has any thoughts about this or can point
> out anything I'm missing or not thinking of.
>
> Any responses would be much appreciated.
>
> Thanks
>
> Gareth
>



Recent Activity
Visit Your Group
Give Back

Yahoo! for Good

Get inspired

by a good cause.

Y! Toolbar

Get it Free!

easy 1-click access

to your groups.

Yahoo! Groups



__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 5 comments |
headers
Justin Daubenmire | 1 Jun 10:36
Picon
Favicon

Re: Re: repository and infrastructure return values

Thanks for the reply.

Do you have a link to the Tasks extension from JP Boodhoo  so I can look 
over the source code. I am familiar with JP.

Do you have a link to sample source code for the TaskResult object?

Regards,
Justin
----- Original Message ----- 
From: "Eben Roux" <eben <at> bbd.co.za>
To: <domaindrivendesign <at> yahoogroups.com>
Sent: Monday, June 01, 2009 2:31 AM
Subject: [domaindrivendesign] Re: repository and infrastructure return 
values

> Hello Justin,
>
> In my repositories I do not trap exceptions.  So 'action' methods (such as 
> insert, delete) return void.  Fetching methods return the aggregate / 
> collection of aggregates.
>
> Since all calls are made from a service layer --- currently using a Tasks 
> extension that I stole from JP Boodhoo :) --- all exceptions are trapped 
> here and wrapped in a TaskResult.  The nice thing is that the TaskResult 
> contains both an ErrorMessages collection and ConfirmationMessages 
> collection (or call them what you want).  TaskResult.OK returns false if 
> there are Error messages.  Confirmation messages can also be sent back ---  
> such as 'Your order has been placed as order number ON-100-01'.  So the 
> {Blah}Tasks.{Method} always returns a TaskResult.  I actually have a 
> 'Value' property on a generic overload for when I send back values (such 
> as a retrieved aggregate).  So a TaskResult<IOrder> for instance.
>
> Of course you can go ape and perform logging on these messages in the 
> service layer (via some appropriate class / provider / factory).
>
> Regards,
> Eben
>
> --- In domaindrivendesign <at> yahoogroups.com, "Justin Daubenmire" 
> <jdaubenm@...> wrote:
>>
>> All,
>>
>> A silly question, but I was just curious what people return from the 
>> infrastructure when performing an insert or delete operation to a 
>> database?
>>
>> For example, do you return an int indicating 1 for success 0 for failure? 
>> Do you return an exception? Do you not return anything from your 
>> insert/delete/update operations?
>>
>> What do you typically have your repositories return for an 
>> add/update/delete operation from your methods?
>>
>> Wondering how folks track errors or problems in these layers and I am 
>> wondering what you do with the errors/messages?
>>
>> Thanks!
>>
>>
>> Regards,
>> Justin
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

------------------------------------
Permalink | Reply | 2 comments |
headers
Eben Roux | 1 Jun 10:41
Picon

Re: repository and infrastructure return values

Hello Justin,

Here is a link to the relevant blog entry:

http://blog.jpboodhoo.com/CommentView,guid,744e085e-efe8-4b63-b6b8-46d53b61e757.aspx

For the very simple TaskResult code I use please mail me at (ebenroux *at* room2010 dot co.za)

I can send it tonight (don't have it at work).

Regards,
Eben

--- In domaindrivendesign <at> yahoogroups.com, "Justin Daubenmire" <jdaubenm@...> wrote:
>
> Thanks for the reply.
> 
> Do you have a link to the Tasks extension from JP Boodhoo  so I can look 
> over the source code. I am familiar with JP.
> 
> Do you have a link to sample source code for the TaskResult object?
> 
> Regards,
> Justin
> ----- Original Message ----- 
> From: "Eben Roux" <eben@...>
> To: <domaindrivendesign <at> yahoogroups.com>
> Sent: Monday, June 01, 2009 2:31 AM
> Subject: [domaindrivendesign] Re: repository and infrastructure return 
> values
> 
> 
> > Hello Justin,
> >
> > In my repositories I do not trap exceptions.  So 'action' methods (such as 
> > insert, delete) return void.  Fetching methods return the aggregate / 
> > collection of aggregates.
> >
> > Since all calls are made from a service layer --- currently using a Tasks 
> > extension that I stole from JP Boodhoo :) --- all exceptions are trapped 
> > here and wrapped in a TaskResult.  The nice thing is that the TaskResult 
> > contains both an ErrorMessages collection and ConfirmationMessages 
> > collection (or call them what you want).  TaskResult.OK returns false if 
> > there are Error messages.  Confirmation messages can also be sent back ---  
> > such as 'Your order has been placed as order number ON-100-01'.  So the 
> > {Blah}Tasks.{Method} always returns a TaskResult.  I actually have a 
> > 'Value' property on a generic overload for when I send back values (such 
> > as a retrieved aggregate).  So a TaskResult<IOrder> for instance.
> >
> > Of course you can go ape and perform logging on these messages in the 
> > service layer (via some appropriate class / provider / factory).
> >
> > Regards,
> > Eben
> >
> > --- In domaindrivendesign <at> yahoogroups.com, "Justin Daubenmire" 
> > <jdaubenm@> wrote:
> >>
> >> All,
> >>
> >> A silly question, but I was just curious what people return from the 
> >> infrastructure when performing an insert or delete operation to a 
> >> database?
> >>
> >> For example, do you return an int indicating 1 for success 0 for failure? 
> >> Do you return an exception? Do you not return anything from your 
> >> insert/delete/update operations?
> >>
> >> What do you typically have your repositories return for an 
> >> add/update/delete operation from your methods?
> >>
> >> Wondering how folks track errors or problems in these layers and I am 
> >> wondering what you do with the errors/messages?
> >>
> >> Thanks!
> >>
> >>
> >> Regards,
> >> Justin
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>

------------------------------------
Permalink | Reply | 1 comment |
headers
Justin Daubenmire | 1 Jun 11:06
Picon
Favicon

Re: Re: repository and infrastructure return values

Thank you. I've also emailed you off list.

Regards,
Justin
----- Original Message ----- 
From: "Eben Roux" <eben <at> bbd.co.za>
To: <domaindrivendesign <at> yahoogroups.com>
Sent: Monday, June 01, 2009 4:41 AM
Subject: [domaindrivendesign] Re: repository and infrastructure return 
values

> Hello Justin,
>
> Here is a link to the relevant blog entry:
>
> http://blog.jpboodhoo.com/CommentView,guid,744e085e-efe8-4b63-b6b8-46d53b61e757.aspx
>
> For the very simple TaskResult code I use please mail me at (ebenroux *at* 
> room2010 dot co.za)
>
> I can send it tonight (don't have it at work).
>
> Regards,
> Eben
>
>
> --- In domaindrivendesign <at> yahoogroups.com, "Justin Daubenmire" 
> <jdaubenm@...> wrote:
>>
>> Thanks for the reply.
>>
>> Do you have a link to the Tasks extension from JP Boodhoo  so I can look
>> over the source code. I am familiar with JP.
>>
>> Do you have a link to sample source code for the TaskResult object?
>>
>> Regards,
>> Justin
>> ----- Original Message ----- 
>> From: "Eben Roux" <eben@...>
>> To: <domaindrivendesign <at> yahoogroups.com>
>> Sent: Monday, June 01, 2009 2:31 AM
>> Subject: [domaindrivendesign] Re: repository and infrastructure return
>> values
>>
>>
>> > Hello Justin,
>> >
>> > In my repositories I do not trap exceptions.  So 'action' methods (such 
>> > as
>> > insert, delete) return void.  Fetching methods return the aggregate /
>> > collection of aggregates.
>> >
>> > Since all calls are made from a service layer --- currently using a 
>> > Tasks
>> > extension that I stole from JP Boodhoo :) --- all exceptions are 
>> > trapped
>> > here and wrapped in a TaskResult.  The nice thing is that the 
>> > TaskResult
>> > contains both an ErrorMessages collection and ConfirmationMessages
>> > collection (or call them what you want).  TaskResult.OK returns false 
>> > if
>> > there are Error messages.  Confirmation messages can also be sent 
>> > back ---
>> > such as 'Your order has been placed as order number ON-100-01'.  So the
>> > {Blah}Tasks.{Method} always returns a TaskResult.  I actually have a
>> > 'Value' property on a generic overload for when I send back values 
>> > (such
>> > as a retrieved aggregate).  So a TaskResult<IOrder> for instance.
>> >
>> > Of course you can go ape and perform logging on these messages in the
>> > service layer (via some appropriate class / provider / factory).
>> >
>> > Regards,
>> > Eben
>> >
>> > --- In domaindrivendesign <at> yahoogroups.com, "Justin Daubenmire"
>> > <jdaubenm@> wrote:
>> >>
>> >> All,
>> >>
>> >> A silly question, but I was just curious what people return from the
>> >> infrastructure when performing an insert or delete operation to a
>> >> database?
>> >>
>> >> For example, do you return an int indicating 1 for success 0 for 
>> >> failure?
>> >> Do you return an exception? Do you not return anything from your
>> >> insert/delete/update operations?
>> >>
>> >> What do you typically have your repositories return for an
>> >> add/update/delete operation from your methods?
>> >>
>> >> Wondering how folks track errors or problems in these layers and I am
>> >> wondering what you do with the errors/messages?
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> Regards,
>> >> Justin
>> >>
>> >
>> >
>> >
>> >
>> > ------------------------------------
>> >
>> > Yahoo! Groups Links
>> >
>> >
>> >
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

------------------------------------
Permalink | Reply | 0 comments |
headers
Gareth Down | 1 Jun 15:18

Re: Re: When using asp.net MVC...



Yes I think a repository should have sole responsibility for reconstituting the entire aggregate root.

I always try to avoid that kind of scenario because you end up with a billion different methods for every object.

You could roll your own lazy load mechanism quite easily, for example if you had a class MyClass with a property of type MyProperty, just make an interface for it IMyProperty and have a class MyPropertyProxy which implements it. When your repository reconstitutes the class set the property's value to MyPropertyProxy. This will hold a reference to the real MyProperty and it will be null by default. The first time one of your IMyProperty's members is accessed then you load the inner MyProperty from wherever you need to then forward any subsequent calls the inner MyProperty.

Or you could do something more clever with dynamic proxy or similar.



2009/6/1 Nuno Lopes <nbplopes <at> gmail.com>


I use the rep not only to encapsulate the mapping to the database but also to other systems in complex environments such as yours. 

Nuno

On 2009/06/01, at 05:41, Hendry Luk <hendrymail <at> gmail.com> wrote:

For command, the main reasons to use services are validation and backend systems.
As for query, backend system is still often a reason I need services.

The problem I have in my project is that most of the entity properties (e.g. Subscription) comes from backend services like billing-engine or TML rather than database. Only minimal subset of information is stored in database, but to get a complete state of the domain entity, simple repository lookup is not sufficient.

We put it behind a service that calls repository as well as remote call to billing engine and TML to populate the rest of subscription detail, but that opens up another can of worm:
1. It doesnt feel right to have the repository to load/persist only half of the entity state, leaving the other half unpopulated which clearly breaks object invariant.
2. No one ever says that repository has to be for database only. Why do we need Service to access remote backend? Repository is a layer that handles entity's states and lifecycle. Any thought about whether I should encapsulate lots of remote infrastructure behind repository (instead of services in application layer?).
3. Loading all entities information from all backend systems is not efficient. 99% of the time we don't need customer's address. Neither do we need how many accounts/susbcriptions they have, what plan they're on, or even if he's still active or not. We need some kind of lazy load mechanism really, but instead what we have is bunch of Service overload like:
getCustomerWithFullDetail()
getCustomerAndAllActiveSusbcrtipionWithoutAddressInfo()
getCustomerWithBlaBlaAndBla()

Thoughts?

On Mon, Jun 1, 2009 at 6:45 AM, Gareth Down <g <at> garethdown.com> wrote:


Hi Jeff

Thanks very much for your reply. Are you saying you'd do things differently if the operation was a command?

Does anyone else have any thoughts on this? Jeff's the only person who's replied.

Gareth



2009/5/30 Jeff Gillin <jeffro3377 <at> yahoo.com>



I would say that for this particular concern you are showing, you don't need a service layer because you are just getting an item to display. When thinking in terms of command query separation, this is just a query and is perfectly OK to retrieve from your controller or presenter.


--- In domaindrivendesign <at> yahoogroups.com, Gareth Down <g <at> ...> wrote:
>
> Hi
>
> I am using ASP.NET MVC for a products I'm working on. I was just wondering
> what the DDD community thought about where the kind of "entry point" code
> should go, i.e. the code that accesses the repositories and actually brings
> everything together.
>
> Quite a few people say that you shouldn't really have very much in your
> controllers at all and they should really just field requests to a so called
> 'service' layer, for example:
>
> http://stackoverflow.com/questions/338816/should-controllers-in-an-asp-net-mvc-web-app-call-repositories-services-or-both
>
> I've started working for a new company and taken on a project where the
> previous developer has a 'service' for each of the entities, eg if there was
> a Product object there would be a ProductService with a few methods like
> GetProduct(int id) etc and basically whenever there's a call to a
> controller, it gets fielded to a service in the same way the person has
> suggested in that stackoverflow answer.
>
> The problem is I think these people are using the word service in a
> different way to the way DDD people talk about services. I think they're
> using the term in the way DDD people talk about repositories. For example
> the product I've inherited there are methods similar to
> GetAllVisibleProducts(), GetAllProducts(), DeleteProduct(id) etc, etc. I
> would say these were repository operations personally.
>
> Eric Evans says, as I'm sure you're all aware "A service tends to be named
> for an activity, rather than an entity - a verb rather than a noun".
>
> Therefore this approach seems wrong to me.
>
> Personally I can't see the problem of having the controller interact with
> the model directly.
>
> For example, I have this method: (I've stripped out a extra code that checks
> for a null entry etc and a security check etc, but you get the idea)
>
> public ActionResult EditEntry(int id, int subscriptionId)
> {
> var subscription =
> subscriptionRepository.FindSubscription(subscriptionId);
> var entry = subscription.Entries.FirstOrDefault(x => x.Id == id);
> return View(ViewModelOf(entry));
> }
>
> Now I can't see what is wrong with that? The user makes a request to edit a
> subscription entry, the controller asks the repository for the subscription,
> finds the entry and returns the View to the user.
>
> Why should I put a service there, aren't I just adding an extra layer for no
> reason? One reason people cite is code re-use, e.g. if you want to use the
> same code and put a different user interface there. But what if I know
> that's never going to happen? I know this app will never have a windows
> forms interface for example.
>
> Another example I've got is this: (note the ActiveUser property calls a user
> repository)
>
> public ActionResult Index()
> {
> return View(ActiveUser.Subscriptions);
> }
>
> That's really simple, is there any reason to add a whole other layer which
> does the same thing? To me it would mean more code to write more
> dependencies to hook up and more stuff to test.
>
> I'd really like to know if anyone has any thoughts about this or can point
> out anything I'm missing or not thinking of.
>
> Any responses would be much appreciated.
>
> Thanks
>
> Gareth
>



Recent Activity
Visit Your Group
Give Back

Yahoo! for Good

Get inspired

by a good cause.

Y! Toolbar

Get it Free!

easy 1-click access

to your groups.

Yahoo! Groups




__._,_.___


Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 4 comments |
headers
Justin Daubenmire | 2 Jun 17:17
Picon
Favicon

persisting entity and value objects



All,
 
I have the following layers in my project:
 
App.UI
App.Presentation
App.Services
App.Domain.Model
App.Domain.Repositories
App.Infrastructure.DataAccess
 
I have a question on persisting an entity and value object to the database.
 
Lets say that the domain has a customer entity with first name and last name properties.
 
 
Currently, in the App.presentation I do something like this:
 
class CustomerPresenter
...
CustomerEntity cust = new CustomerEntity();
AddressValueObject add = new AddressValueObject();
 
add.Street1 = UI.Street1;
add.City = UI.City;
 
cust.Firstname = UI.Firstname;
cust.Lastname = UI.LastName;
 
cust.Address = add; // value object
 
My questions are:
 
1. Should I call the customer repository from the presenter class?
 
custRepo.Add(cust);
 
2. The address value object, should I process it in the customer repository or have an address repository?
 
custRepo.Add(cust);
addressRepo.Add(cust.Address);
 
3. should I pass the UI parameters to the App.Services layer and create a new domain customer entity there rather than in my presenter class or is it ok to new up entity/value objects in the presenter?
 
Regards,
Justin
 


__._,_.___

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Permalink | Reply | 3 comments |

Gmane