Hi,
With no intention of committing heresy, I am looking to see if there is a good alternative to CSLA. I have used it for a while and find it quite useful, but I find that it adds a lot of complexity for features that I will never use.
I do not feel like re-inventing the wheel and write my own lighter-weight framework, but all I really need is a framework that supports the same type of business object philosophy as Rocky uses, but without remoting, n-level undo, etc. The features I need are not many: Generic Business Object baseclasses for Sorting, Filtering, Validation & State / persistance (roughly).
Any help on this would be greatly appreciated.
Thanks,
Jim
I know some people have stripped out remoting and n-level undo, etc as they needed a CSLA Lite to work on a mobile platform - It's easier to remove stuff than try and write it in the first place :-).
Someone posted on this I recall in the past - have a search on CSLA Lite.
CSLA.Net is getting to the point now where it does so much for you with minimum effort in your business object code. Version 3.5 will take that further and cut down the property get / set code even more. CSLA isn't lightweight in terms of functionality but it is lightweight in terms of code you need to write - at least I think so. You never know how your business objects might be used in the future, or on what platform - so being able to support all these scenarios is a big bonus.
I've been there - developed a Windows application and there was no thought by the business that a Web UI was required at the time. 18 Months later the business decided they wanted part of the application on the web. Reused my business objects and had two thirds of the application done just by adding the library into my web project. Management love you when that happens.
You've got the microsoft framework blocks but I find they are sledgehammers to crack nuts sometimes - depends on the size of your nut of course.
Richard.
I agree with Andy. There is no overhead to NOT using certain features.
I would stick with CSLA and write the code as if those things might happen some day - then you won't have an issue when Management asks for them in a year or two.
Joe
ajj3085:
I'm not aware of anything similar that's focused on business objects.
The only other business object framework I'm aware of is Mere Mortals - http://www.oakleafsd.com/ - you can check out an evaluation version.
Been a couple years since I used it, can't remember if it had undo, pretty sure it did not support remoting. I wouldn't say it's less complex than CSLA.
There's lots of reasons I like CSLA over MM - community is bigger and more active, seems cleaner and easier to work with, you've got books, and the price is better. So personally I prefer CSLA, but MM is an option.
Hi and thanks for the reply.
I guess the preceived complexity from my end is in the data access parts. It's been a while since I coded in CSLA, but from what I recall: when you get an exception in the data access code, you usually wind up somewhere deep in the csla framework very far from where the problem originated. Usually I wind up stopping the debugging session, placing a breakpoint in the insert or update code (or whatever) that where the problem most likely originated and restart debugging. Then I check out the SQL statement that causes the exception and go from there.
There are a few more scenarios like the above when there just seem to be a lot of complexity added by the framework. Usually not a problem unless an exception gets thrown from deep inside the framework and it makes it harder to debug.
But part of the equation is of course the fact that I do not know the framework very well. I wear a lot of different hats (constantly jumping between languages and environments), so it is hard to dedicate the time to really get to know it in depth.
Jim
I would agree with the others and suggest that you try and stick with vanilla CSLA if you possibly can. Just don't use the bits you don't need. That's what we do.
CSLA provides a great structure and patterns for you to follow to get the most out of the code you do actually have to write.
You get great support from the framework author (Rocky) from his books, e-books and on this forum. And also some great community support on these forums from a very knowledgable group of people that share some common development ideals.
FWIW !
Yes, I believe you are right.
Now, I did come across a post in a thread about CSLA where person A stated that he was very surprised that person B used the framework straight as it is, since according to person A, it was meant as an "example framework" and not meant to be put directly into a production environment. He argued that it was supposed to be used as a base that you can re-write to fit your specific needs.
While I can see that this makes sense in some cases, it seems to me that you are better off doing like you guys suggest in this thread - simply don't use the features you don't need. If you start customizing it, you are of course on your own and cannot easily use future updates.
Anyhow, thanks for your advice. It is great to have an active forum like this.
Jim
Now, I did come across a post in a thread about CSLA where person A stated that he was very surprised that person B used the framework straight as it is, since according to person A, it was meant as an "example framework" and not meant to be put directly into a production environment. He argued that it was supposed to be used as a base that you can re-write to fit your specific needs.
This is probably someone reiterating things I said in the past. CSLA started as a side-effect of my books and wasn't originally intended to be a "framework". But somewhere in the late 90's people started sending me "bug report" emails on my "framework" because they were using my example code as a basis for their apps.
When I first created CSLA .NET I sort of treated it like a framework, but still not really like a "product". It was still primarily a side-effect of the books.
Somewhere around CSLA .NET 1.3 I realized it was a framework whether I liked it or not. This was around 2003.
By the time I created CSLA .NET 2.0 (in 2005) I had given in entirely - source control, versioned releases, continuing documentation updates, etc.
So for the past 4 years or so the recommendation has been to go ahead and use CSLA .NET as-is, only modifying it if absolutely necessary. And over that time I've incorporated a lot of extensibility points to help people achieve flexibility without having to alter the core implementation.
Of course, as always, the software is provided as-is with no warranty or guarantee of any sort - read the license for details.
Just an idea :
In CSLA, we can do many many things but everybody doesn't need everything.
So it will be good to edit a such list (perhaps that exists already) :
You don't want to use so do the following
- remoting ……………………
- n-level undo ……………………
- ………….. ……………………
It is true that there's support for some "legacy" technologies. Ones that I'll probably drop from ProjectTracker in 4.0 (not from CSLA .NET mind you - just from ProjectTracker). They include
Other "legacy" technologies are too vibrant to be dropped (so are they legacy?). They include
Things that clearly need to be added
Yes, once 3.7 for SL3 is complete the real work begins :)
ajj3085,
Yes I know how to use the stack trace, but the point I was bringing up is that the origin of the problem is not in the stack trace if the error is in the data access code. Example:
This is line 951 of Rule.cs: dataLayer.ExecuteNonQuery(sqlString);
The sqlString is incorrect so it throws an exception. The stack trace (top part only):
Csla.dll!Csla.DataPortal.Update(object obj = Count = 169) Line 329 + 0x74 bytes C#
Csla.dll!Csla.DataPortal.Update<Csla.BusinessListBase<Jims.ProTrack.BusinessLayer.RuleCollection,Jims.ProTrack.BusinessLayer.Rule>>(Csla.BusinessListBase<Jims.ProTrack.BusinessLayer.RuleCollection,Jims.ProTrack.BusinessLayer.Rule> obj = Count = 169) Line 273 + 0x7 bytes C#
Csla.dll!Csla.BusinessListBase<Jims.ProTrack.BusinessLayer.RuleCollection,Jims.ProTrack.BusinessLayer.Rule>.Save() Line 612 + 0x40 bytes C#
Jims.ProTrack.PresentationLayer.exe!Jims.ProTrack.PresentationLayer.RuleMaintenanceForm.SaveChanges(bool promptUser = false) Line 198 + 0xe bytes C#
Jims.ProTrack.PresentationLayer.exe!Jims.ProTrack.PresentationLayer.RuleMaintenanceForm.uxAddRuleButton_Click(object sender = {Text = "Add Rule"}, System.EventArgs e = {X = 50 Y = 7 Button = Left}) Line 303 + 0x9 bytes C#
I cannot see an easy way to directly identify the culprit "dataLayer.ExecuteNonQuery(sqlString);" on line 951 of Rule.cs from that stack trace. I can get an idea of where it is coming from, stop debugging, place a breakpoint at line 951 of Rule.cs and start the debug session again so that I can scrutinze the sqlString, etc.
Without the csla, I would have the offending ExecuteNonQuery just a few lines from the top of the stack trace.
Not a huge deal, just wanted to clarify the added complexity I was referring to.
Jim
Jim,
If you are concerned about figuring out where exceptions occured, you can implement something like this :
Public Function ExtractTrueException(ByVal ex As Exception) As ExceptionDim cslaEx As DataPortalException = TryCast(ex, DataPortalException) If cslaEx IsNot Nothing Then
Return cslaEx.BusinessException End If Return ex End Function
CSLA Business Methods wraps exception into a DataPortalException. The beauty of which is it contains the Original Exception in the BusinessException field and the BO in the which the exception was thrown BusinessObject field. You just need to extract this BusinessException to get the real cause of the problem.
Regards
Yang
Copyright (c) Marimer LLC