Linking properties

Linking properties

Old forum URL:

SartriX posted on Monday, November 28, 2011

Hello =)

We have a fairly specific software architecture in mind, and wonder how this can be done in CSLA. Due to a very volatile set of requirements and multi-cultural targets, most of our business objects have to be broken down to interchangeable components. In our previous software a customer has expanded to over 150 properties, not even considering child relations.

For this, we'ld like to achieve a 'Person' should have a configurable amount of 'BusinessBase' modules server-side, but communication to the front-end should result in simplified composed objects, consisting of and pointing to the several components' properties and commands, without requiring duplicate binding and validation programming. Additional complexity is that loose coupling is required, so an 'address' field on the front-end object could point to several implementations.

Is it possible to have a 'front-side' BusinessBase implementation which can easily refer the properties and validations of 'server-side' BusinessBase classes, while maintaining loose coupling? The front-side objects could be considered a form of ViewModels, although they should be used for .Net WinForms clients primairly (later also Web and WPF)


PS: The above question is based on limited research into the CSLA.Net. There's no experience with CSLA other as the examples. The purpose of the question is to determine whether CSLA.Net can fit into our new strategy.

RockfordLhotka replied on Monday, November 28, 2011

First, if you want your client and server to be loosely coupled, you should be looking at the creation of a service-oriented system that is composed of 2+ applications. None of these applications should share any code - they must be independent in order to achieve independent versioning and remain loosely coupled.

Lots of blog posts on the topic here:,category,Service-Oriented.aspx

That means you are creating a client application that exposes a user interface (often called an "edge application" because it is on the edge of the system), and a server application that exposes a service interface. These are two separate applications that communicate with each other via contractually defined messages.

The result is that (within limits) you can version either application independently from the other, and thus you have achieved true loose coupling. The message contracts are the point of agreement between applications, and restrict any coupling to operation/data contracts - about as loosely coupled as is possible.

CSLA is particularly good at helping you to build a typical edge application. This is because CSLA-derived business objects fully support data binding for all UI technologies, and make it easy for the edge application to implement any business logic that you want to run on the client to provide the user with a rich, interactive experience. The "data access" layer for an edge application typically calls the services exposed by any server applications that are part of your overall system - though some edge applications will also talk to local storage (client-side database, isolated storage, etc) to provide some features.

CSLA can also be used to create service applications, though it isn't as strong in this scenario because there is no concept of data binding, and usually no concept of state beyond whatever exists for the life of a single service invocation from another application. However, the CSLA rules engine can still be quite useful when building a service application, and the layered architecture is always a good idea. Even if you don't use CSLA itself, I strongly recommend consistent application of the layered architecture CSLA supports, because that results in maintainable code for any type of application.

SartriX replied on Tuesday, November 29, 2011

Loose coupling between server and client ofcourse is part of the design, but the situation I was attempting to lay out is one which is completely server-side. The eventual objects available by either service or edge for the client, e.g. the interface of the server, should hide the more complex modular composition of the several entities.

While such a modular approach could be seen as collection of parent-child relations, our old software does not support many complex parent-child relations. And for the sake of continueity and useracceptance, we must provide objects to the old system in the old fashion, yet with all the new validation and business logic behind it. On the end of the new client software, we want to out-source this to designers, without burdoning them with complexities.


Example: We wish to provide the client-software with a simple Customer object, having any amount of arbitrary fields, of which a subset includes Address, City, Country. Internally however, this is composed of an Address object (Street, Number, Postal, City, etc, plus historic timestamps valid from, valid till). The requirement for loose coupling comes from the fact that Italian addresses and validation works different from Dutch addresses, and therefor needs a different module (likely even programmed by a different person)

Copyright (c) Marimer LLC