What's The Impact of Bye Passing the Data Portal?

Smeat posted on Wednesday, June 28, 2006

I am about to start developing a new web based app where remoting will not be used and wonder if I can gain performance by bye passing the data portal.

For instance, in my public static Enquiry GetEnquiry(int ID) method, instead of having

return DataPortal.Fetch<Enquiry>(new Criteria(ID));

I was thinking of having

Enquiry o = new Enquiry();

o.DataPortal_Fetch(new Criteria(ID));

return o;

Am I right in thinking that this will have no impact other than to prevent me switching to remoting?

TIA

Smeat

ajj3085 replied on Wednesday, June 28, 2006

I believe you are right; you'll lose the ability to switch to remoting if you need to later.

That can actually be a pretty big deal, if the time comes where you NEED remoting now to provide better scalability.

The peformance hit of the DataPortal is negligiable, you won't be gaining much peformance at all by bypassing it, so I'd recommend against it.

As Rocky points out in the book, reflection is much much quicker when compared to the peformance of the data access code round-tripping to the database.

Are you having peformance problems now, or are you trying to optimize? If you're having problems now, I suggest looking at your queries for optimization. If you're not, I wouldn't worry about it just yet.

HTH
Andy

Smeat replied on Wednesday, June 28, 2006

I'm not really having any performance issues with the framework at the moment though any improvement would be a bonus.

The main reason for wanting to bye pass the data portal is that I am trying to persuade my collegues to buy into the CSLA framework though i'm hitting my head against a brick wall as they have briefly played with version 1.0 where they were running against the CSLA source code and expressed concerns about the amount of processing that goes on under the hood.

Personnaly, I don't see any issue here though if bye passing the data portal will help them to buy into the framework then it will be worth doing.

As far as being able to switch to remoting at a later date, I believe it would be a fairly simple task to bring the data portal back into my objects at a later date as all calls are nicely situated withint he factory methods.

Regards

Smeat

RockfordLhotka replied on Wednesday, June 28, 2006

You can read through chapter 5 to see how the data portal is implemented. The local proxy incurs as little overhead as possible, and the data portal itself detects when the "server-side" code runs in-process and bypasses pretty much all the expensive work (serialization, passing context, impersonation, security checks, etc). In short, you gain very little by bypassing the data portal when running in local mode.

What you gain by using it is enforced consistency of code. ("enforced" might be a bit strong...) The reason is that the data portal forces a high level of consistency in how your object interacts with the data source - providing a logical "layer" for your data access code. Without the data portal, or some equivalent, you run the risk of having decentralized data acess code - a developer could write data access code anywhere in the object, bypassing good OO design entirely and destroying any benefit you might hope to gain from using CSLA at all.

Not that the data portal is the only way to get this level of structure. A formal DAL can help, as can code reviews. But the real danger, even with a DAL, is that a developer might start directly accessing the database behind properties, or in arbitrary methods in an object - places where a Command object or some equivalent should probably be used.

Without some enforcement of the logical concept of "client-side" and "server-side" processing, most developers just cheat. It is a byproduct of human nature...