Can the DataPortal be Ignored?

MadGerbil posted on Tuesday, September 19, 2006

Greetings:

I've got a developer that I'm showing the CSLA framework and the project he is gonna do first is a very small 1-2 user application that will never require an application server.  The dataportal is something I don't understand very well - and this developer is entirely new to the topic - so we were wondering if for a tiny application you could just ignore it.

When a root object loads children, and grandchildren can calls be made directly to constructors that make direct calls to fetch, save, update, delete - completely ignoring DataPortal methods?  Is there a downside to doing that in this situtation.

I wouldn't mind seeing a version of CSLA that is built sans DataPortal yet keeps all of the other functionality.  It's a brilliant bit of code, but overkill for applications that we are writing - they just have no chance of ever getting big enough to need application servers.

Thoughts?

ajj3085 replied on Tuesday, September 19, 2006

The downside is that the data portal forces you to keep code into a few well defined method.  That is, you know data access code won't creep into other areas which it doesn't belong.

Also, should your tiny app grow and you need to scale it, you'll have to recode to take advantage of the data portal.

I'm not sure its overkill; it provides some good benefits and the peformance hit is very very low.  As Rocky and others have explained many times, the cost of reflection is insignificant compared to the cost of talking to the database itself.

That said, if you really don't want to use the DP (and I don't recommend not using it) you don't need to modify Csla; just don't call the data portal.  Your factory method would end up like this:

public static MyRootObject GetMyRoot( int id ) {
        MyRootObject result;

        result = new MyRootObject();
        result.DataPortal_Fetch( new IdCriteria( id ) );

        return result;
}

You should keep using the DataPortal_fetches; this will help you keep your data access code isolated to one portion of your class.

HTH
Andy

DansDreams replied on Tuesday, September 19, 2006

I think all of the solutions we'd offer (and I just erased mine) come from the assumption that the DP is a great thing with no real performance cost, so why would you want to abandon it.

Thinking in those terms, I think I'd challenge the beginning premise of your question.  If your application is really tiny the question probably should be more of whether you need CSLA at all.  If you think you'd benefit from CSLA then I think it is very unwise to start tinkering with the implementation of CSLA without specific reasons.

Some have argued that the reflection DataPortal_XYZ paradigm doesn't "feel right" and the data access part of CSLA should work like <insert your favorite solution here>.

I'll share that I have just spent a couple months (not solid) taking a very serious look at CSLA vs. some home-grown alternatives that solve some application development problems in a superior way, but at the end of the day I've decided there's tremendous value in using a more widely used framework.  But the only way that's really valuable is to use it in common ways.

So, in summary, I'd say that if you've decided to use CSLA on this project then part of the value of that comes from doing so in standard ways, especially when there's no real tangible reason for doing otherwise.

guyroch replied on Tuesday, September 19, 2006

MadGerbil:

the project he is gonna do first is a very small 1-2 user application that will never require an application server. 

Never say never, we never know what the future will toss our way :)

If _your_ current project will never see the light of day to grow beyond 1 or 2 users then I say go ahead, use CSLA as-is and use it to learn.  Then, when the time comes, you'll have all you need to build a _bigger_ application based on CSLA - or at the very least you'll be in a better position to make the decision - go with CSLA or not to go with CSLA.

Hope this helps.  BTW, I agree with DansDream post.