I have been reading the alpha release of your book and will continue to digest this information over the next couple of days. The book is very clear and well written and the end result is Business objects that are OO.
I would agree with Mr. Lhotka that OO is the way to do things, especially over a data centric approach. This remains to be the problem with SOA. Sure, you can share data... but you're still blind as to what the business rules are, data isn't enough alone.
I still have some remaining concerns and I would appreciate any help with addressing them:
1) It seems likely microsoft will address this problem area directly in time. If it is built directly into .net it is more likely to have better support.
2) How long will this framework be supported? What happens if Mr. Lhotka gets eaten by a pack of wolves on a camping trip tomorrow?
3) Has anyone tried a OO database like http://www.intersystems.com/index.html? Does this help solve the problem? Where are the alternatives to Mr. Lhotkas framework? I see a lot of ORM but really nothing that create OO business objects... why is this?
kyle.l.watson@gmail.com:
1) It seems likely microsoft will address this problem area directly in time. If it is built directly into .net it is more likely to have better support.
2) How long will this framework be supported? What happens if Mr. Lhotka gets eaten by a pack of wolves on a camping trip tomorrow?
Hmm... good question. At worse, you have the source code.. so you could maintain it.
3) Has anyone tried a OO database like http://www.intersystems.com/index.html? Does this help solve the problem? Where are the alternatives to Mr. Lhotkas framework? I see a lot of ORM but really nothing that create OO business objects... why is this?
Search around, I know Rocky has posted on OODbms before. I don't think they really solve the problem; relational does still seem the best way to actually store data. OODbms "solve" the problem by shoving the object into the database and saying "done," from what I have been able to gather.
What leads you to believe this? Even if it's true, Csla.net is very mature, and it will take a while for MS to reach that same level of maturity.
Well it just seems like the ONE thing that microsoft has going for it is the development tools and I think this makes their product very appealing to business owners. Thus, business objects is much more appealing than datasets any day of the week.
Hmm... good question. At worse, you have the source code.. so you could maintain it.
This is true. The community could certainly attempt to maintain this code when bug reports come in.
Search around, I know Rocky has posted on OODbms before. I don't think they really solve the problem; relational does still seem the best way to actually store data. OODbms "solve" the problem by shoving the object into the database and saying "done," from what I have been able to gather.I'm not really aware of any competing frameworks; lots of ORMs abound, but a true business object framework.. When I was searching for such a thing, Rocky's book was the only one I found. That was three or four years ago though.
This is very confusing for me because I see these arguments and they make a lot of sense in Rocky's favor. However, I am wondering why, if Rocky is very correct, why the industry doesn't recognize this and why microsoft itself doesn't build business objects directly into the pie. I agree so much with Rocky in that data has very little meaning when you take it out of its business context. And that is why I agree that SOA is mainly marketing noise and perhaps business rules need its own language. Having a business rules engine or something baked directly into your development tools would be awesome.
Well... if you look at MS's history, it's fairly obvious (at least to me) that MS does not share the BO view. MS has had a data-centric view ever since ADO first came about, and they built their entire IDE infrastructure around that. They are starting to move away from that with EF, but it's still largely a data-centric view - after all, the "E" stands for Entity object, which is vastly different from a Business object.
(I would also disagree with you that business owners view objects as "better" than datasets any day of the week. Most developers do not see that - otherwise MS and VS would have evolved differently - and most business owners - at least those I've worked with - wouldn't care one way or the other.)
Having said that, switching from a data-centric viewpoint to an object-centric viewpoint is not nearly as easy as it sounds. MS was at least eventually smart enough to build their IDE's around interfaces, thus giving you the ability to do it and get a pretty decent design-time experience (also one of MS's decisions, and also another bone of contention among developers.) But you see how much work it takes to get that, and it still doesn't interface as well as the native .NET objects do. Providing a "better" interface to manage an object-centric system would incur even more overhead to Visual Studio, since they couldn't really abandon the current viewpoint.
Just MHO.
HTH
- Scott
(I would also disagree with you that business owners view objects as "better" than datasets any day of the week. Most developers do not see that - otherwise MS and VS would have evolved differently - and most business owners - at least those I've worked with - wouldn't care one way or the other.)
I guess I have had a difficult time with datasets. Mainly with embedding business rules in them and I have been working with them for the last 2 years fairly exclusively. Datasets are great for building a UI in two seconds and getting data into and out of the ui quickly. But they fail horribly when you start adding business logic to the app in my opinion.
In my experience, "business owners" are non-technical folks who don't really pay too much attention to how we solve their problems - only that we do solve them. Some of them tend to think I work just over the "black magic" line, so to speak. ![Smile [:)]](/emoticons/emotion-1.gif)
Perhaps your definition of a business owner is different than mine, or perhaps yours have a different mindset than mine.
As for working with DataSets - well, if DataSets (and its predecessors) were all that and a bag of chips, Rocky probably wouldn't have had near the incentive to start the CSLA project in the first place.
- Scott
I agree, I think many developers still think in terms of data and in my contracting history the majority are using DataSets and not using business objects (either CSLA or non-CSLA based). (Heavy Sigh).
I'm not sure if this is becauses of lack of understanding, or they just don't know there is a better way, or are comfortable with what they do know and happy to build systems like they've done for ever.
But I'm glad I discoverd CSLA and business objects all those years ago.
ajj3085:
Well, that's exactly the problem; embedding business rules into datasets or other data object invariably leads to all sorts of nastiness. We did exactly that (before I ever heard of Csla) and it lead to a really weird and fragile design.
I think this comes down to the simple difference between data-centric and behavior-centric design.
If your application is designed purely around data, with behavior as a secondary consideration (and an often informal one at that), you can often create something quickly, but it is difficult to maintain or modify over time.
If your application is designed purely around behavior, with no formal thought given to data, I suspect the same poor results would occur. I think this is hypothetical, because our industry is so data-focused that I've never seen this happen.
My hope with CSLA is to get people to at least consider behavior at an equal level with data. Yes, data is the "most valuable asset of an organization". But data without behavior is meaningless. Useless.
So I don't argue that data should be analyzed and normalized and carefully organized into databases. But I do argue that behavior should also be analyzed and carefully organized into some first-class structure.
In my case, I think that first-class structure should be a set of responsibility-based, behavioral business domain objects. And this is what CSLA .NET tries to support - the easy creation of these first-class behavioral objects. These objects use data, but aren't designed around data. Just like the database is useless without behavior, but isn't designed around behavior.
I have no problem with people who want to create business layers using function libraries, workflows, rules engines or other techniques. That's all good too, because there's a formal "home for behavior" in those models. (though honestly, I do think those techniques are inferior to a good OO design)
Things like a DataTable or EF entity onto which you graft some behavior are ultimately doomed (imo), because they are data constructs first, and any behavior is an after-thought. Behavior is still second class, and in the end that'll lead to disaster.
Conversely, if you have the discipline (and can overcome the tooling limitations) you could create EF entities that are responsibility-driven, and coincidentally have data (as required by the behavior). I suspect this will be easier in EF version 2 or 3, but today it is sadly not practical for anyone but the most dedicated and masochistic.
Which is why I think CSLA .NET is a good answer. If you do the OO design "right" (by which I mean you use the single-responsibility pattern, and make your objects exist to fill roles in your use cases), the end results can be really great.
Is this more up-front work? Probably. Does it save time/money/effort over the lifetime of the app? I absolutely believe it does.
But data without behavior is meaningless. Useless.
This is where I agree the most. I believe you said somewhere that this was a limitation of Soa - as the behavior/context of the data is unknown.
If I recall correctly, when I was doing my search, I looked at:
Strataframe
Ideablade
Deklarit
Deklarit at least seemed to give the appearance that one was trying to build out _from_ the business object. I don't recollect that well from years ago, so I don't quite remember. In the end, though, the fact that CSLA is essentially free and one had the source code and community support, that was difficult to beat.
The one thing we wanted to avoid was being on our own little island dependent on some 3rd party dll we couldn't control or change. CSLA avoided that, and it's probably one of the primary reasons we chose CSLA.
Copyright (c) Marimer LLC