Advice on how to deal with CSLA being used as a non-domain service

[alturium]

Hello folks,

I am looking for advice in what appears to be a misuse of CSLA.NET for our architecture.

Observations: Our architecture/design leader has divided our team into two groups, one to serve up CSLA BOs and the other for application development. What has happened over the last two years is that the "service" side creates BOs that do not fit user scenarios.

Recently, I have been pushing for more interaction, but even requests for changes to BOs may take one to two weeks (user stories are maintained separately for each group). Really, the service" group is creating DataObjects (with IDs for each property that require a lookup, as an example) instead of real Business Objects.

Conclusions: I realize now that the BOs really belong to the application team but I'm not sure how to persuade our leader to change his architecture. If anything, BOs should be a cross-functional endeavor between the two groups.

Backup from Marting Fowler: "When looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval. A smart team will optimise around this and plump for the lesser of two evils - just force the logic into whichever application they have access to. Logic everywhere in other words. This is an example of Conway's Law[5] in action."

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." -- Melvyn Conway, 1967

SO my question is two-fold: Is my observations and conclusions correct? What can I say to convince my management to change?

Thank you in advance

[jonnybee]

How about some real life stories.

First look at this post in the CSLA FAQ about MVVM: http://www.lhotka.net/cslanet/faq/Mvvm.ashx

I consider BO objects to be a "rich" ViewModel without the actions/commands/verbs. See: http://www.lhotka.net/weblog/InitialThoughtsOnMVVM.aspx

I was part of a large project where we had multiple teams and applications - all using CSLA.NET for business objects. At it's peak we were 40+ developers! Each team owned the silo for their application - ie: they had all responsibility from the UI to storage service (which was cobol based on IBM Mainframe). So the big question is where does the BO belong - it belongs to the teams that create the UI!!! The BOs should have the shape and data required for a given user scenario.

We also created one common architecture/expert team to handle TFS, Build, Deploy, CSLA.NET, other frameworks and training.

[alturium]

Thanks Jonny!

Your help is greater than you realize :-)

I like the idea of one common architecture/expert team. We have one CSLA expert but he is confined to the service side, even though he has extensive WPF UI expertise. Sigh

[jonnybee]

I was the CSLA expert on our team and I found that the really big challenges was to get developers to a) understand the business object methodology (where do I start?). Always start with the business objects first and then create the UI and use databinding. b) understand the business rules system (and sync/async rules) c) understand databinding d) how to unit test the business objects

If you wish more help or discussions you may contact me!

[rockfordlhotka]

fwiw, CSLA is designed with the intent of the domain objects reflecting the needs of the user scenario, which almost always means the needs of the UI.

If CSLA is just used for some entity data layer thing, then it is being misused - all its benefits are probably being ignored, and there are better options (like EF) for dealing with data entities.

[alturium]

Hi Rocky and Jonny,

This discussion about “respresentations”(CSLA BO) of the “resource” (entity/domain model), reminds of … REST! When I mentioned this similarity to my guru co-worker he said that REST stole ideas from CSLA, is that true? Well, maybe is steal is too strong. I’ve read Roy Fielding’s dissertation and it’s a great read. I've also been reading up on Microservices and Domain-Driven Design, and playing with Akka.Net. Which leads me to the next comments...

[Thread Hijack Alert] These recent binge readings (once every 10 years) about Microservices+REST+DDD highlighted a few issues I see with CSLA.

The first is not the fault of CSLA per se, but I have to be honest and say that I have never been happy with OOP. No one ever does it right, and no one ever refactors their object graph when it starts showing its first cracks. Another issue is what I would call the object "method" sequencing.

An example: I was writing CUDA code a few years ago, using the N-Body example, and damn I was having a hard time with the C++ vs C code examples. That was because the C++ followed the object sequencing : ObjA.Init, ObjB.Setup, ObjA.SomeMethod, ObjB.SomeOtherMethod, then ObjA.use(ObjB), then ObjA.ReallyDoSomethingMethod, and by the time I got to ObjA.ReallyDoSomethingMethod, I had forgotten in my small brain what had to occur in ObjA.Init. Like some trivial memalloc or memcpy operation. The C code example was…well...functional and much, much easier to understand. The data to be operated on was passed as a parameter (vice properties in C++), and code style was, really, more “functional”.

CSLA relies on an object graph. Creating a good object graph is difficult. Understanding the sequence of object methods before the final Root.Save() can also be difficult, as any sequence of ObjA, ObjB,…ObjN “methoding” can be difficult to comprehend.

Another example: I was recently playing around with Akka.NET after playing around with TPL Dataflows and working with async/await/dispatcher/TaskFactory.StartNew, and I realized that concurrency is a much bigger problem than I realized. How much more so with distributed processing and distributed transactions. Coding in Akka.Net is functional and pointed out the shortcomings of OOP and object graphs. I have formed a recent and tentative opinion that functional programming is probably superior to OOP, and will increase in importance.

I would like to point out that CSLA does lend itself to “functional-like” behavior. Using criteria to create/fetch a BO is brilliant. But then I see people create a class variable to store a BO and I just let out a /sigh.

Along with the shift to services (err, microservices), I would favor a service implementation to handle business logic vice an object graph of BO. The service would handle validation, updates to the underlying domain model, along with more context-driven code that is not easily disguised or digested into an object graph.

Anyways, these are ruminations and observations I hope may help you in your efforts (toward a Functional CSLA ! LOL, okay…maybe…).

Lastly, my guru co-worker and I are both amazed that you (Rocky, and probably you too Jonny) respond so quickly to emails, after all these years! You are held in high esteem :-)

Thanks!

[jonnybee]

You can have services of many kinds (WCF/REST/ASMX/HTTP and proprietary versions all coupled with databases).

And especially when creating rich client applications (WindowsForms, WPF, SL, WinPhone, WinRT) you maintain state and use databinding and you have a number of interfaces and behavior that you must implement. This - to me - is where CSLA is a good framework that hides a lot of the complex interfaces and base classes. You can still use the same classes for

As a "consumer" of microservices you can use whatever data access you like while still having a "familiar" object structure to use in the UI. As for validation - it is all about giving the user feedback as soon as possible - not wait until the triggers a save and then get a more or less cryptic message back from a failed save. This fits really nice with CSLA.

CSLA is NOT a data access framework. CSLA only requires an object graph when the USE CASE needs an object graph. It depends on the use case and which data do you need to perform a certain use case. That is when you will get success!

Unfortunately, it seems like your project has not used CSLA in this manner and you are struggeling with that.

Have you read Rockys last blog post on a simple web api wand CSLA? http://www.lhotka.net/weblog/SimpleServiceImplementationWithCSLANET.aspx

[alturium]

Your right about "struggling". We have bit off other new technologies as well, such as WPF, and so I am not seeing the incredible leaps in productivity overall. But it goes back to misuse as the main cause. We also need to allocate more time for training.

I checked out the blog post. Very interesting but also very simple.

BTW how do feel about the performance of CSLA on Mono (Xamarin)? From what I understand, it doesn't support WPF (but WinForms is). For LOB application developers, we have obviously been in a quandary the last few years, but it seems WPF will hang in there. Running some form of XAML/CSLA/Mono would be an extra bonus.

Thanks Jonny :-)

[jonnybee]

I haven't done any projects on Mono but from the tests done earlier I have found the WindowsForms implementation in Mono is very lacking in terms of databinding.

[tfreitasleal]

Since there are several GUI toolkit on Mono, concerning databinding are there better alternatives?

[jonnybee]

Probably, but I have no experience with them. Hopefully other people om the forum can provide insights to this.

[rockfordlhotka]

It seems to me that monodevelop is written using GTK+ or something right? Perhaps that one is mature?