CSLA class bloat??

rhinoishere posted on Friday, November 03, 2006

Let's use "ProjectType" as an example.

In the past I would have created a Project business object and added a method to it that would return a dataset of project types.

However, CSLA requires that you create a seperate class called "ProjectTypeList" (or "ProjectTypes").  Along with that, you need a "ProjectTypeInfo".  And you probably will also need just a "ProjectType" class.

So that's three classes that would not have existed at all in the past.

Now, I understand why it is much better to utilize the smart data of a business object rather than a dataset. But how many classes is too much to be contained inside one assembly?  100?  500? 1000??

I worry for two reasons:

1) I worry about new developers being overwhelmed when they open our business object library.
2) Also, at what point does the number of classes start degrading performance?  Is that even a concern?

thanks, Ryan

ajj3085 replied on Friday, November 03, 2006

You can easily ask those two questions about the .Net framework itself.

The best way to tackle #1 is to have good API documentation.  The nice thing about Csla is that many of those objects you won't need to worry about.  If it doesn't have a public factory method, that's not a 'starting point.

If the number of classes becomes too great, you probably have many isolated use cases in your assembly.  Many use cases interact with a few others (maybe) and that's it, so it should be possible to move them to another assembly.

So, I wouldn't worry about having too many classes.  I would worry more that your poor new developer makes a one line change that breaks 50 different classes than I would about having them learn 50 different classes.

guyroch replied on Friday, November 03, 2006

I don't think the number of classes in any given assembly will have any performance implication - other from the fact that it might take a bit longer to initially JIT compile the assembly that is.

Most of us are using code generation with partial classes.  This helps to offset being overwhelmed by the amount of code, or _look_a_like_ code from one class to antoher.

At the end of the day though, I think Csla does exactly the opposite.  Because all of the business objects have the same skelleton, developers will be able to immediatly make out the difference between _framework_ code and _business_logic_ code... and this will help you down the road.

If you're concened about the number of classes in one given assembly, nothing prevents you from splitting your library into smaller, more managable, assemblies.

 

malloc1024 replied on Friday, November 03, 2006

You can use façades to simply the interface of the business layer if it becomes too complex. 

Business objects provide many advantages over datasets.  This is more so in larger projects.  IMO, it would be a mistake to go with datasets over business objects in any large project.