By choyt - 7/26/2007
Hi AllI want to pass a business object from one method to another. At first this seemed pretty simple but I'm not having much success except to do it as a generic object. Am I missing something really dumb, is there another way or is this just it? Public Sub DoIt(b as strataframeobject) ' in this example, i want to be able to pass different objects and load the results into cache end function Thansk!
|
By Greg McGuffey - 7/26/2007
Well, it is actually that simple. However, if you want your method/function/sub to handle different types of business objects then you'd need to use BusinessLayer (Microfour.StrataFrame.Business.BusinessLayer).
I.e.
Sub DoIt(a As MyBO)
will work with MyBO objects only, were as
Sub DoIt(a As BusinessLayer)
will work with ANY business object.
Obviously what you do with the BO will determine which is better. Hope that helps! 
|
By choyt - 7/27/2007
Thanks GregThat helps. The problem I'm having now is that my FILL methods are custom created and are not being recognized in the sub. I will probably have to resort to late binding and if that is the case, I doubt I will follow this path. Clay
|
By Trent L. Taylor - 7/27/2007
Greg is correct. You just need to type your parm as a BusinessLayer or BusinessLayerBase and it will then accept any BO. You can then DirectCast or CType it if you know what to expect on the other side. Otherwise you can just leave it typed as the BusinessLayer and interact with the "known" methods and properties.
|
By Greg McGuffey - 7/27/2007
choyt (07/27/2007)
That helps. The problem I'm having now is that my FILL methods are custom created and are not being recognized in the sub. I will probably have to resort to late binding and if that is the case, I doubt I will follow this path.
Clay,
A few options to possibly avoid late binding.
- Fill the BOs before they are passed. This may or may not be feasible, but it is at least more possible that you'd know what the Fill methods are on the calling side.
- It might be possible to create an abstract class that inherits from BusinessLayer and has a MustOverride method that is used to fill the BO. See the code below:
Public MustInherit Class CachedBO
Inherits BusinessLayer
' This method must be overridden in classes that inherit from CachedBO
Public MustOverride FillForCache()
End Class
Note that this is the entire class needed. You'd then change any BO that is to be cached to inherit from CachedBO instead of BusinessLayer and implement the FillForCache() method in each of them and have DoIt use CachedBO:
Public Sub DoIt(a As CachedBO)
a.FillForCache()
End Sub
This could work very nicely if the parameters needed to fill the BO are common between the Fill methods, or you can figure out some other way to get the Fill methods the data they need, like using properties on the BO. If data needed by the Fill methods is different then this likely won't work out.
- An interface might work, but only if you don't need any of the method/properties of the BusinessLayer and the Fill methods can be generalized (have the same signature).
Anyway, some food for thought.
|
By choyt - 7/27/2007
Thanks all! Greg...I am going to take your advice.
|
By choyt - 7/27/2007
Hi FolksThe inheritance idea works great except for one problem. When your BO inherits from an abstract class (instead of MicroFour.StrataFrame.Business.BusinessLayer directly) the designer no longer works. The only drawback to this that I can see is having to manually edit properties such as CRUD, required fields, etc. Can anyone else think of a reason not to do this? Thanks! Clay
|
By Greg McGuffey - 7/27/2007
I didn't know that about the abstract class. Well, you could just make the CachedBO a normal class and then make the FillForCache an actual method:
Public Class CachedBO
Inherits BusinessLayer
' make it overridable, and it does nothing...subclasses must implement this.
Public Overridable Sub FillForCache()
End Sub
End Class
Now when you inherit, you just override the FillForCache() method. This should work with the designers, its just normal inheritance. In this case you are trading a cleaner coding style (abstract class...explicitly defining the intent of the abstract class) for a more convenient coding style (use of designers, less typing/typos).
|
By choyt - 7/28/2007
Thanks GregThis did the trick. I truly appreciate the help.
|
By Greg McGuffey - 7/30/2007
Good to hear. Any time I can help, I'll be glad to.
|
By StrataFrame Team - 7/30/2007
Yeah, whenever you have a component designer attached to something, you have to make its base class non-abstract. Because the designer actually creates an instance of the base class and uses that as the root of the designer... rather than the class itself (I have no idea why, but I'm sure they've got a good reason for doing so). So, when we have a base class for our business objects, we generally create a property/method that needs to be overriden and throw a NotImplementedException() from within the base class (rather than making it abstract/MustInherit, because you can't), so that way, when you forget to override it in one of your classes, you'll get a nice red error window telling you what method you forgot to override. (just don't forget to NOT call the MyBase.Method() or it will still throw the exception  ).
|