Our agency is again having one of those "let's get rid of CSLA" meetings where the arguments will be that it's too complicated and we don't use a lot of the functionality. It sounds like they want to write their own framework.
I could use some arguments supporting CSLA. We have a lot invested in it. We're also a small shop. I've created frameworks in the past and know how difficult it is. I will likely be the only person in the room who will argue for CSLA. I could use some arguments that both developers and managers can understand. Thanks.
I guess that's not the kind of answer you're waiting, but the point is "Why do they say it's too complicated?"
Is it because they have to write a lot of code in a specific way (CSLA way)? Every framework has its own way of writing code.
What about not having to write code? Why don't you try one (or several) of the CSLA code generators?
If this is a "pure" engineering decision (unlikely at best), one way to go about this is to list the various types of functionality that the others want to do: data binding, new/dirty tracking, 1, 2, 3, n-tier development, validation, authorization, and so on. Compare and contrast each item by discussing what is needed in each of these areas and what it would take to accomplish it starting from scratch. These forums are a rich source for enumerating the problems that can come up and the solutions that CSLA offers. At some point, your team should have sufficient data to decide which direction to take. Quite frankly, CSLA is complicated because it provides a fair amount of functionality over a set of topics that are of general interest. But the .NET framework is several orders of magnitude more complicated.
If this is a "mine is bigger than yours" decision, then all of the marshaling of ration arguments is not going to do you very much good.
Good Luck.
Hi,
if the options are a) writing and using an own framework and b) using an existing and prooven one, I'll always tend to choose b).
Years ago I walked the other path and created my own little framework. This was ok and a good experience since I learned a lot of that, esp. in the OO field. But since demands evolved I had to realize that writing a framework is very much time-consuming and in fact hard stuff. This counts the more , the smaller your shop/organisation is (and it was a 'one man band' by that time). So, one should have a framework, but not have to build one. (I think Rocky stated that once, too) With all the given respect I don't think that your organisation is more capable in developing a framework in a short time than Rocky and the whole CSLA-community did over the years. And by the way: Is framework-designing and -coding your core business? If not, drop this plan.
In fact THIS is quite a good argument for managers, since developing a framework by your own will result in a huge amount of time consumed by non-productive (or: non directly productive) work, which will raise your cost!
Not using a lot of the functionality may count, but be aware that business demands tend to rise and so do the requests regarding the used framework. For an example we initially only used winforms related stuff within CSLA, but are on track to switch over to SL/WPF. Having a framework that's core supports more than one approach (winforms) doesn't restrict yourself in choosing UI-technology or any other stuff like data access.
Even your own framework will dictate a certain way to use it, in that there's minor difference to use CSLA. But what with other/new team members? CSLA may be not as widespread as other technology, but surely much wider than a homebrewed framework, created by your own. This will make it more easy to integrate new members to the team. There is training/books/videos etc. outside, so using CSLA can be adopted my newbies.
And to the last: CSLA enforces separation of concerns in some aspects. It's no data-access technology and it's no UI technology. It's all about business objects (with some d.a. and esp. UI related stuff to make things work) This makes team development much more easy. This the more, the smaller your shop is, since in that case project management may be not that big at your side...
Just my thoughts about it. Hope it helps
Volker
Thanks all, this helps. I've really been dreading this meeting. I've come to realize over the years that often what I'm fighting at these meetings is laziness.
I found a good blog post by Scott Guthrie about technical debates. I forwarded it to the meeting organizer.
I don't know anything about your organization. But in my experience, "Complicated" is code for "I want to do it myself". CSLA caters to solving business problems. Some developers don't want to solve business problems; .they want to solve cool technical problems that they make up themselves. Business-centric developers who as you put it "have a lot invested" in CSLA would not choose to abandon it. The types of developers making those arguments might just want to build frameworks (like Rocky) and want you to pay them to do it under the pretense of "simplifying". You probably don't have any control over it but maybe your organization needs to ask the question as to whether you have the right kind of developers in your "small shop" if they want to throw away something that is working just to make it themselves.
Or just ask this question: "How much new revenue will abandoning CSLA generate for the firm?". When they can't answer...you got em'.
I had a feeling you folks would be just as passionate on this issue as I am
Just out of curiosity, please let us know the results of your meeting.
Just got done with the meeting today. Basically the way it went was that we listed a bunch of things on the board that a business object framework should do. I was probably the only one in the room who realized this, but CSLA already met most of the criteria.
I heard things like it's not truly open source, that Rocky's the only one who's supporting it, that it's too bloated, that it's too hard to use. I don't think anybody can truly appreciate what Rocky has done until they try to do it themselves though.
I might be in the minority among developers these days, but my main goal is to write less code. I have deadlines to meet and customers with high expectations. I think solving business problems should be our main area of concern. I like CSLA because it handles many of the implementation details I used to have to deal with in the data and UI layers, so I can focus all of my efforts on the business objects.
Anyway, no decisions were made, which was good. I will push back if they suggest writing their own framework though. Are there any other competing frameworks out there, or just ORM tools?
FYI, here is the list of what they all consider important
The best answer: CSLA have the best <Quality Control> ; Save money in the long term.
We run 1 project for 15 years on the old CSLA and 2 new projects on the new CSLA.net 4 for 2 years...
So, that appears to be the only things Csla isn't, with some cavets.
One, what the hell is a "lightweight" or "heavyweight" framework? No one seems to really be able to define what they mean to me.
The POCO / not inherit from framework. Why? The only concern I've heard is that it would be hard to move to another framework. Maybe, but I'm personally not even aware of anything I'd consider a "competing" framework. Regardless, you'd need to come up with a solution to those on your own. I'd be hard pressed to imagine moving away from Csla to come up with something that would be more maintainable.
Logging can be added easily.
The last point, no black box. Why is your company using .Net at all then? Never mind MVC, WPF, WCF, or even a string or int.
Don't give them any ideas
Ha, sorry. I've been having similar informal discussions on bringing in Csla, so I understand your frustration. Some of mine probably leaked in. :-)
Anyway, where would they go if not .Net? Java isn't exactly open source either..
I heard things like it's not truly open source, that Rocky's the only one who's supporting it, that it's too bloated, that it's too hard to use. I don't think anybody can truly appreciate what Rocky has done until they try to do it themselves though.
The definition of OSS is slippery. To my knowledge the only point where CSLA might not be "open source" is because I don't use a blessed license. But I also don't use a "poison pill" license like GPL because I don't necessarily want to further a political agenda with my software :)
Usually the definition of OSS is that the source must be open and so free-as-in-speech (my repository is public), some version of the software must be free-as-in-beer (all versions are free). Ideally OSS has some public venue for feedback and public bug/issue tracking (this forum and the bug tracker are public).
If they want a specific business model, like using GPL to be "OSS" and to force any real users to buy the commercial license - that's fine - but that's a subset of OSS.
Are there any other competing frameworks out there, or just ORM tools?
There have been some that have come and gone over the years. I've been doing this for 15 years now, and I'm not aware of anything that has the same longevity. Not even on the Java side - though maybe Spring has been around this long?
Some current/recent ones (spelling could be wrong):
Not all of these are open source or free (maybe none of them are actually) - most people think I'm f*cking crazy to do what I do frankly...
But I'll share this: when I was early in my career I benefitted greatly from freeware/shareware (that's what OSS used to be called). And by greatly, I mean some of that software boosted my career in amazing ways, when I needed it most.
I've never met the people who helped me so much, and couldn't even thank them via the Internet because it didn't exist yet.
So among numerous other motivations, CSLA is in part, a way to hopefully do for other people, what was done for me.
I know, that sounds sappy, and I'm not entirely altrustic obviously (I don't give away the books/videos), but it is also true.
I know, that sounds sappy, and I'm not entirely altrustic obviously (I don't give away the books/videos), but it is also true.
You're an inspirational person to me Rocky. I noted that as such on my Facebook page.
Buy the Using CSLA 4 Ebook Series
Even if not all the books are completed these are the most up-to-date ebooks and will give you great information on how to create apps with CSLA4.
I am pretty much a novice programmer. My wife has a small business and I have been rewriting a work order program that I wrote in Visual Basic 6 about 10 years ago. I chose to learn and use CSLA because I knew that I could never create something that robust on my own. Has it been easy for me to learn CSLA? No. I have watched all the videos that Rocky produced at least 4 times each and am reading the ebooks as they come out.. I have had a steep learning curve because I was not a very good programmer to start with and also I had the great idea of incorporating CSLA with Silverlight into Sharepoint. Most of my problems have arisen from figuring out all the security issues between Windows Server, SQL server, IIS, WCF, Silverlight and Sharepoint (Thank God for all the brillant people who help out ignorant people like me on the web!).
I am over most of the bumps now and I have some of the application done and working. I don't profess to know everything about CSLA but I learn new things every day and I have never regretted the decision to use it. I have a feeling it will be supported for years to come and it will be a lot easier to upgrade and make changes than if I would have written my own framework. Also if something were to happen to me, I believe it would be easier for someone else to understand the system and support it.
On my team I have four new hires (each less than a year of experience now, two with a month and a half) straight out of college and all of them are now coding in CSLA.
Intro book (C#) followed by some hands on explanation of an existing CSLA editable root with child objects and the CSLA training videos and that was enough to provide the fundamentals for them to get rolling.
To argue against rolling a different framework, I'd completely agree with the sentiment - "how much revenue will it generate"?. And is there any true sentiment for how long it'll take? And what they'll truly gain?
Beyond that, there's a business risk in having one guy or a couple guys write their own framework, presumably convert product, and then go *poof*. Then where will you be... people who don't know why the framework was created in the way it was created...
One thing I always liked about CSLA is the fact that it's being used in the industry, it's proven, there are training tools, Rocky is tremendous about moving us along to new technologies, and the community is outstanding.
Too complicated? Tell that to my four new hires who are doing CSLA + Silverlight w/ MVVM and a DAL using DTOs (the sweet spot one Rocky suggests)... it really isn't that complicated once there are example classes in your solution for new hires to follow (i.e. you're not beginning your application from the ground level).
At the risk of going off topic...
When you say DTOs, are you referring to using an ObjectFactory and the corresponding attributes on your business class? I was just looking at that today and was very interested. It would be great if you had a link to a video or blog entry talking about the "sweet spot". I'd like to share this with the group.
When you say DTOs, are you referring to using an ObjectFactory and the corresponding attributes on your business class? I was just looking at that today and was very interested. It would be great if you had a link to a video or blog entry talking about the "sweet spot". I'd like to share this with the group.
This technique is discussed, along with examples, in the Using CSLA 4: Data Access ebook.
Copyright (c) Marimer LLC