Should "DataPortal_Delete" be a static method?

Should "DataPortal_Delete" be a static method?

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


rxelizondo posted on Tuesday, December 29, 2009

Hello

I was messing around with the CSLA this afternoon and could not help noticing that the “DataPortal_Delete” method‏ is expected to be implemented as an instance method and not a static method.

This is somewhat awkward to me because “DataPortal_Delete” is there to allow for immediate deletion and not deferred deletion. And unless I am completely missing something, immediate deletion will not load the object so you can’t count on object state.

I think “DataPortal_Delete” should be changed to be a static method, why? Well, for one, because this will formalize the fact that “DataPortal_Delete” is a stateless method. Another benefit is that it could make the application one or two whole millisecond faster since we would not have to create an instance of the class in order to run “DataPortal_Delete”. We also can give garbage collection a break sicne we are creating less instances of the class.

Anywaym in reality, I think the most important point (to me at least) is that it would formalize the fact that “DataPortal_Delete” is a stateless method.

Just a call out.

Thanks.

RockfordLhotka replied on Tuesday, December 29, 2009

I doubt you'll save 1-2 ms :)  Maybe 1-2 nanoseconds, and even that is being a little silly since .NET can create/dispose many thousands of objects in that time.

The problem with static methods is that you can't override them, extend them, or otherwise use standard OOP techniques to work with them. While they have some very real advantages, static methods also have some very real disadvantages.

rxelizondo replied on Wednesday, December 30, 2009


Thanks for answering Rocky,

Just one last thing I would like to mention, if you look at the standard implementation for an immediately deletion method it would look something like this (lower and greater than characters replaced by { and } to avoid markup issues with the post):

public class FooBar : BusinessBase
{
public static void DeleteImmediately(.........)
{
DataPortal.Delete{FooBar}(........);
}
}

Notice that "DataPortal.Delete" method includes the type of the object (FooBar in this case).

I believe that behind the scenes, the CSLA will create a FooBar instance and call DataPortal_Delete there. So basically, there is no chance for the DataPortal_Delete to behave in a polymorphic way.

In other words, if you specify a FooBar type, the DataPortal_Delete of FooBar will be executed, if you specify a Xyz type, then the DataPortal_Delete method of Xyz will be executed. So there will never be polymorphic behavours and therefore never a need for the override or extension need.

Perhaps DataPortal_Delete will truly never need to resort to standard OOP techniques!

Any way, I am sure I am wrong, just having a difficult time trying to stay out of trouble :)

Thanks.

RockfordLhotka replied on Wednesday, December 30, 2009

There's no doubt that making it static is possible. Maybe even desirable - your arguments are very valid.

There's a backward compat question, in that a change like this would break a lot of objects. Though personally I know I don't use immediate delete all that often - but my templates include this code, and a lot of people follow the templates, and thus have this method.

It is also the case that, today, a base class could provide the implementation. So if someone hooked their DAL into their object model through a set of base classes (and I know people do this) then this change could force them to implement a static method in every business type, where today they just have it implemented in the base type, and only override when necessary.

It is the loss of overriding the method that concerns me - because that would essentially block the creation of base classes that implement or hook into a DAL.

Copyright (c) Marimer LLC