Is it possible to have an intermediate class with BusinessBase<T>?

Is it possible to have an intermediate class with BusinessBase<T>?

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


JCardina posted on Tuesday, February 28, 2012

I have a CSLA 4.x project I'm starting out with and there are going to be a *lot* of objects that have the same basic properties. 

Rather than re-implement them over and over which makes no sense I'd like to have an intermediate object implement those standard properties and then the final object that inherits from that intermediate object with the unique properties defined.

I'm not sure that BusinessBase will allow for this though.

I.E. Something like this:

public class StandardObject : BusinessBase<StandardObject>

{

//bunch of standard properties and or code

}

 

public class Customer: StandardObject

{

//bunch of customer object specific properties and business rules etc.

}

I'm not sure what the best approach to this might be due to the generic nature of BusinessBase, any help greatly appreciated.

 

RockfordLhotka replied on Tuesday, February 28, 2012

Yes, this is a fine idea, but your intermediate class must be generic. Or you can't use the generic RegisterProperty overloads, and that is a mess.

The one area you should think about carefully (and the reason I recommend against what you propose) is that your data access code will get complex. Think it through carefully and completely before going down this road.

JCardina replied on Tuesday, February 28, 2012

Sorry, still just as confused as ever.  What would my declaration look like then for the intermediate and final classes?  That's the part I can't wrap my head around I guess.

I'm not sure how this affects the data access code, that's probably the critical bit that will make this unviable.

What would you do if you had 60 some odd objects and every single one has the same 5 properties that all require the same default values be set on construction?  Same data access code etc etc?  Copy and paste just "smells" wrong to me.

 

 

RockfordLhotka replied on Tuesday, February 28, 2012

I am pretty sure there are examples in the FAQ, but I don't have time to search them out for you right now.

JCardina replied on Tuesday, February 28, 2012

Cool, thanks Rocky, I'll have a look.  I did search but didn't find anything.  I had no idea this was so commonly asked it was in the FAQ.  Perhaps the search terms I used were wrong. 

If I get it working I'll post some helpful info here for others in future.

JCardina replied on Tuesday, February 28, 2012

RockfordLhotka

I am pretty sure there are examples in the FAQ, but I don't have time to search them out for you right now.

I could not find anything in the faq (searching it or reading through it) that illustrates the correct way to declare an intermediate class using CSLA 4 business base (or there is another faq I don't know about or I'm just plain blind), however the Business object design section there is a link that just says "forum thread" with no explanation and after looking at it, it seems relevant in a meta kind of way:

http://forums.lhotka.net/forums/p/3465/17230.aspx#17230

Where you stated "The key, imo, is that you don't want to replicate behavior (methods). Replicating properties/fields doesn't matter - they can be code-genned or created with snippets. There's little to no variation in a property - they are just stamped out like widgets."

Perhaps this might be what you directed me to the FAQ for and what you're really saying here if this is still your thinking on what I asked is that even though it's a huge replication of code it should be done because we're talking about properties not behaviour.  I know it's just boilerplate code really but my every instinct is to eliminate repetitive code wherever possible and it feels completely wrong to have the same bit of code copied and pasted over and over.

I guess I'll take your answers to my questions to summarize as yes it's possible to have an intermediate class with BusinessBase<T>, it's uncommon enough or tricky enough that you don't know it off the top of your head (which makes me feel a little better about having trouble figuring it out Smile )however don't do it because you don't advise replicating properties anyway and there may be some mystery problem with data access if I try to do it which I will only discover when I try to do it.

RockfordLhotka replied on Tuesday, February 28, 2012

I'm sorry. I honestly thought there was a FAQ entry that included the code for all the basic intermediate class. My pointing you to the FAQ was intended to be helpful, not frustrating.

That post IS still my thinking - inheriting to get properties is just a total PITA, and I absolutely recommend against it. Just think through the data access model for such types and you'll probably come to the same conclusion - it is a total mess - either leading to unmaintainable code, or to duplicate code, or to complex code, or all of the above.

Whether you accept the cost/complexity to get perceived reuse - that's a choice ultimately up to you.

My pointing you to the FAQ, as I say, was an failed attempt to get you the few lines of code you need to create the basic intermediate base classes. Just a f*ck up on my part, for which I am sorry.

RockfordLhotka replied on Tuesday, February 28, 2012

I believe this is the correct declaration (off the top of my head):

  [Serializable]
  public class MyBusinessBase<T> : BusinessBase<T>
    where T : Csla.Core.IEditableBusinessObject
  {
  }

JCardina replied on Tuesday, February 28, 2012

No worries Rocky, I'm getting square eyes and general grumpiness, time for a break.

I appreciate your help as always and it was helpful because I had not read that big thread before about business object design which was helpful in other areas of my work. Smile

I agree that it's really not worth the hassle if there are potential problems down the road and anything that causes more complexity at the UI level is definitely not worth doing no question.

Thank you for taking the time.

Copyright (c) Marimer LLC