Where to put methods that don't fit nicely into a fetch,update etc

Where to put methods that don't fit nicely into a fetch,update etc

Old forum URL: forums.lhotka.net/forums/t/1459.aspx

rhinoishere posted on Wednesday, October 11, 2006

I am finally beginning to put CSLA into real-world use, but I am confused on one point.

Doesn't every business object have methods that interact with data that don't fit nicely into a fetch,update etc? 

Where do methods such as these go?

For example, in the past when I created business logic, I would often create them in three classes: object, object list, and object data acces. Using a Carrier business object as an example I would end up with:

Carrier
CarrierList
CarrierDAO

The relevant part to this post lies inside CarrierDAO.

There is a method in there called CustNumFromTrackNum.  It grabs a tracking number from the data source (based upon criteria passed in), from that tracking number it extracts a customer number and that customer number is what is returned from that method. 

So where would I put a method such as this using CSLA.

thanks for any help, Ryan

William replied on Wednesday, October 11, 2006

I can think the CustNumFromTrackNum() method as a private (i.e. helper) method in your new "Carrier" business object class, which might be used in the DataPortal_XXX() method as needed.
 
Regards,
William

rhinoishere replied on Wednesday, October 11, 2006

Thank you for your reply.

What I'm worried about is mudying up the business object with a whole bunch of "helper methods".

It makes me think that maybe I am designing my BO's incorrectly (I'm new to all this...).

So, do you think that helper methods inside a business object are fine as long as they are private?

Helper methods are a necessary evil and should not be viewed as bad design, right??

thanks again, Ryan

William replied on Thursday, October 12, 2006

There is nothing wrong to include helper methods in your BO so long as it helps your BO. As in this particular scenario, you should invoke the helper method(s) in any one of the DataPortal_XXX() method so that your data access code is running in the correct context (e.g. transaction).
 
However, in my opinion, if you are including too many (although a very subjective term) helper methods that look like "utility" methods, you might need to rethink your object design. As Rocky always stress, objects are modelled by behaviors.
 
Regards,
William

ajj3085 replied on Thursday, October 12, 2006

You might want to encapuslate this in a private nested class which subclasses CommandBase.

Copyright (c) Marimer LLC