CSLA cioncerns

CSLA cioncerns

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


BillyM posted on Wednesday, September 26, 2007

I am impressed with CSLA design patterns and really want to go this way, if possible. However, I am getting the following feedback from our offshore team:

Our main complaint with CSLA is that it is tedious to program as you need to code a lot more and that the performance is slow.  ... Also, the performance is cause for concern as one query in the prototype took 3 seconds when it should have been less than one second without CSLA.

I am not sure of the details here as I have not followed up with them due to time-zone issues. However, I am wondering if this is likely an isolated issue specific to them or a general one (I haven't seen it). Is performance a known problem with CSLA?

Also, as far as much more coding, I am puzzeled? If there is less coding without using the framework, is it at the expense of losing functionality that should be included in a well-written application?

ajj3085 replied on Wednesday, September 26, 2007

Much of the tedious stuff can be code genned.  As for performance, are you calling CanWriteProperty CanReadProperty without hard coding the method name?  That will be a big performance hit because it uses reflection each time to determine the name of the property which needs to be checked.

Also, there can be other peformance problems if you're not setting RaiseListChangedEvents to false before some list operations, because processing these events can take a lot of time.

I had an operation that took 3 seconds to do (remove items from a grid) and once I shut off RaiseEvents (and fixed a bug in my code that wasn't honoring that) performance became almost instantaneous.

BillyM replied on Wednesday, September 26, 2007

I don't have details as to their performance issues as this was the first I heard about their concerns... just trying to do due dilagence on what to ask and potential pitfalls. If performance is a general issue, then obviously the framework cannot be used. However, if it there are pitfalls and workarounds, it does solve many issues in n-tier business development.

xal replied on Wednesday, September 26, 2007

Well, that kind of complaint sounds to me like: "I don't want to learn CSLA. And calling a datareader inside Button1_Click() is much faster."
Over the years I've seen people post in this forum objections to csla of many types, some well thought and with some relatively valid arguments, but the complaint they gave you seems to be of the lazy kind. :)

So, do they actually work with any specific architecture? Or just make a huge winforms/asp.net project that has everything in it?

But anyway, some years ago, I ran some benchmarks like datasets vs csla and csla outperformed datasets by far. Not to mention all the added benefits of Csla like validation, mobile objects (allowing for multiple comunication technologies like enterprise services, remoting, web services and now wcf), scalability, etc.

Also I don't think "much coding" is an issue, given the many code generation alternatives we have nowadays...


Andrés

BillyM replied on Wednesday, September 26, 2007

Andres,

Your POV is what concerns me. Of course there will be a learning curve, but at the end of the day it is OUR application and not the offshoring team. If they take the common route and throw everything into every tier in order to get something built quickly and cheaply, we wind up with an application at less cost up front but a maintenance nightmare down the road. Before I pull the plug on this approach, I need to level-set that their concerns are legitimate.

I an really interested in hearing feedback from those who have built enterprise-grade applications using CSLA in the real world.

ajj3085 replied on Wednesday, September 26, 2007

Billy,

Yes, many people do use it.  You can check out this page to see a partial list.

You need to find out the specifics of the offshore teams problems; as I said, coding property getters and setters can affect performance greatly, because if you use CanReadProperty() or CanWriteProperty() without specifying the property name, Csla uses reflection to figure it out... and reflection is SLOW.

You also should point the offshore team to the various code generator templates that Csla has.  They can be found in the contrib forum.

BillyM replied on Wednesday, September 26, 2007

I will get more detail from them. I am incouraged by the fact that they do like the framework and see the benefit of using it if they can solve the performance problem. From the feedback here so far, it sounds as though this is not necessarily something that everyone is experiencing and thus unavoidable, which indicates that whatever is causing it can be addressed.

DesNolan replied on Thursday, September 27, 2007

I started 3 months back with an offshore company. The first two weeks I paid them to read the CSLA book. Then I started sending them some basic business classes that were code generated. And now I'm encouraging them to do their own code generation. Between use of the framework and code generating the tedious property related stuff they should be just as well off as if they used Microsoft typed datasets to access the database, from an initial productivity point of view. This ignores all the other wonderful advantages that CSLA offers, that your application will ultimately stand to benefit from.

By the way, I only asked for one programmer initially, but 4 people were trained instead, so I've no complaints with this offshor firm.

Cheers,

Des Nolan

Copyright (c) Marimer LLC