Wbmstrmjb posted on Monday, November 13, 2006

So obviously you cannot override static methods but my question is if there might be some way around it?

I am building a base class that will wrap the CSLA BusinessBase and handle the CRUD in a uniform way. Then my classes will all inherit from this base and set their own properties so that the base class knows what properties each object has.

The base class needs to be able to define the CanAdd, CanEdit, CanGet, etc. so that each object can have it's own permissions. These functions are static as they are called by the factory methods (which are obviously static).

Any ideas on getting around this issue without having to move all the test logic up to each of the inheriting classes?

Thanks,

Michael

Bayu replied on Tuesday, November 14, 2006

Wbmstrmjb:
So obviously you cannot override static methods but my question is if there might be some way around it?

I am building a base class that will wrap the CSLA BusinessBase and handle the CRUD in a uniform way. Then my classes will all inherit from this base and set their own properties so that the base class knows what properties each object has.

The base class needs to be able to define the CanAdd, CanEdit, CanGet, etc. so that each object can have it's own permissions. These functions are static as they are called by the factory methods (which are obviously static).

Any ideas on getting around this issue without having to move all the test logic up to each of the inheriting classes?

Thanks,

Michael

Use a generic method which accepts the Type of object for which you wish to know the CanAdd/CanEdit/etc. flag:

Public Shared Function CanAdd(Of TObject) As Boolean

You can compare the TObject (or TObject.ToString) against a database table to determine to permissions for this particular type of object.

Tip: load the permissions only once into a hashtable or dictionary and cache it there. ;-)

Bayu

Wbmstrmjb replied on Wednesday, November 15, 2006

Thank you so much for your responses. I guess I am having a hard time with grasping the suggestion by Bayu. The way I read it, I'd put all of my checking in the base class and therefore it would need to know about all the different possible types of objects I may create that inherit that class (obviously I could just have it load a collection of objects from a DB and then it would "know" based on the DB).

But what if the objects don't all "work" that way? Can I not write custom CanAdd, Can Edit, etc. functions in the derived classes that can "override" the base functionality? My creative juices have run out.

Thanks,

Mike

RockfordLhotka replied on Thursday, November 16, 2006

Here's some "code for thought"

public abstract class ABase
{
    private static Dictionary<Type, bool> _list = new Dictionary<Type, bool>();
    public static bool CanAdd<T>()
    {
      if (_list.ContainsKey(typeof(T)))
        return _list[typeof(T)];
      else
        throw new Exception("Type not available");
    }
    protected static void SetCanAdd(Type type, bool value)
    {
      _list.Add(type, value);
    }
}

public class AChild : ABase
{
    static AChild()
    {
      SetCanAdd(typeof(AChild), true);
    }
}

JoOfMetL replied on Tuesday, November 14, 2006

in the base class :

public static bool CanAddObject()
{
return true;
}

for the object which inherits of the base class

public static new bool CanAddObject()
{
......
}

ajj3085 replied on Tuesday, November 14, 2006

I wouldn't recommend this method, as using new breaks some OO principals pretty badly.

Bayu replied on Tuesday, November 14, 2006

ajj3085:
I wouldn't recommend this method, as using new breaks some OO principals pretty badly.

The C# new keyword equals VB's Shadows right? In that case I certainly go along with this recommendation.

Bayu

ajj3085 replied on Tuesday, November 14, 2006

Not too familar with VB, but I believe that's correct. new in C# allows you to 'override' anything, marked virtual or not, and allows you to change the method signature as well. I think that's what Shadows does, correct?

Bayu replied on Tuesday, November 14, 2006

ajj3085:
Not too familar with VB, but I believe that's correct. new in C# allows you to 'override' anything, marked virtual or not, and allows you to change the method signature as well. I think that's what Shadows does, correct?

Yups.

So I guess my original suggestion (several posts up in this thread) remains a valid one. At least one that so far sustained the scrutiny of design-guys like Andy. Wink [;)]

Regards,
Bayu

JoOfMetL replied on Tuesday, November 14, 2006

Why don't you recommended this method ?

ajj3085 replied on Tuesday, November 14, 2006

It breaks inheritance. Normally you have the same static method on base and subclasses. With new, thats no longer true, because you can change the methods access or return values. This is probably more true with instance members than static ones.

There's really no reason to declare the method in the base class, unless the base class is not abstract. If the base class can be used as is, then its acceptable to declare security members there. But if its abstract, its better just to leave it off, because you'll probably want to ask the subclasses what security is allowed anyway. You can't inherit static members, so there's no reason to include 'base functionality.'

pelinville replied on Tuesday, November 14, 2006

Wbmstrmjb:

So obviously you cannot override static methods but my question is if there might be some way around it?

I am building a base class that will wrap the CSLA BusinessBase and handle the CRUD in a uniform way. Then my classes will all inherit from this base and set their own properties so that the base class knows what properties each object has.

The base class needs to be able to define the CanAdd, CanEdit, CanGet, etc. so that each object can have it's own permissions. These functions are static as they are called by the factory methods (which are obviously static).

Any ideas on getting around this issue without having to move all the test logic up to each of the inheriting classes?

Thanks,

Michael

A couple of other options.

1. Do they really have to be static/shared? You could create the class then check their CanXXX() methods. This way you could use simple inheritance. Expanding on the this you could define an interface then have your classes implement the interface.

3. An alternative is to use attributes.

4. Don't override. In the base class method retrieve the values from a store (config file, DB etc) based on the type of the subclass calling it. (Or use the static method to read the attributes of the subclass.)

5. Use shadows. From what I understand the main problem with it is that you might call the wrong method (the base classes instead of the sub class). But if you limit the scope of the methods to protected and the base class is MustInherit then the chances of this happening are not real likely.

RockfordLhotka replied on Tuesday, November 14, 2006

I think Bayu's early suggestion is the best overall option, and it is one I considered - and may reconsider - for the framework itself. I didn't feel confident enough in the overall concept when I was writing the book, but Magenic now has a project using this technique and it is working quite well.

The problem of course, is that the methods really do need to be static/Shared. Otherwise the UI would be required to create a "dummy" instance of the object to enable/disable top level menu options or links - and that seems quite odd. The UI should be able to ask whether the user can do basic operations without having to first instantiate the business object.

Bayu replied on Wednesday, November 15, 2006

RockfordLhotka:
I think Bayu's early suggestion is the best overall option, and it is one I considered - and may reconsider - for the framework itself. I didn't feel confident enough in the overall concept when I was writing the book, but Magenic now has a project using this technique and it is working quite well.

Yey! I 'won'! ...... Cool [H]

Just kidding. ;-)
Great start of my day. Stick out tongue [:P]

Thanks.

Bayu