CSLA .NET

I am a member of a development team that is ramping up to rewrite some internal business applications.  The team has been building a framework for the new business applications for a few months now.  We have adopted portions of the MS patterns and practices software factories (web client factory and web service factory). 

I had been wrestling with access control and persisting object trees when I ran across CSLA.  I was surprised to see many (all?) of our framework issues addressed in this framework. 

I have just started to review the CSLA framework.  I am a little confused about the WCF support in the framework.  I had planned on having a business logic project that would be exposed through a WCF based web service created through the p&p web service software factory.  Does anyone have any experience with this?  Would CSLA replace the software factories or would it work WITH the software factories?

---

Building tomorrow's legacy applications today!

The way applications are usually built in Csla is the typical n-tier approach.  UI, business layer, data access layer, database.  If you need to seperate physically the business layer from the data access layer, Csla can do that with a config file change.  That's were Wcf comes into play;  business objects run their code at the client as well as a server, and so need to move across the wire.  Wcf is one of the ways business objects can move across the network so that the data access code may execute on the application server.  After the data code completes, the object is returned from the application server back to the client.

HTH
Andy

Thanks for the reply Andy.

I was specifically concerned about the whole concept of mobile objects.  The microsoft patterns and practices web service software factory (WSSF) introduces a service interface layer that acts as a point of entry into the business logic.  The business objects do not cross that boundary. 

That implementation of WCF requires the  business objects get translated / mapped into a data contract which itself gets embedded in a wcf messages.  From what I have done so far pretty much the business objects map 1:1 to a data contract.

From the little I have read CSLA is simply serializing objects across the wire and rehydrating them in the UI.  I was looking into a more service oriented approach and was wondering if anyone had combined CSLA with the web service software factory.

I am slowly going through the 600+ page business objects book to try to get a little more up to speed, any input would be appreciated.

---

Building tomorrow's legacy applications today!

Well, if you're building a web service that's fine.  Csla objects can still travel from the web server to an application server though to improve security (at the cost of performance).  You then would use your BO to fill a DTO which is sent out from the web service.  A DTO comes back to the web service and you re-create your BO, pop in the new values and you can then see if your business rules are met.  That scenario is a good use of Csla.  The client side of the web service is it's own application and you can use Csla there too; the difference is that instead of actually doing the save, the DataPortal_XYZ methods would make calls to the service and return appropriate state to indicate if something failed.  It depensd on what you're doing and how you're architecting your application(s).

You may want to read some of Rocky's thoughts on SOA too; he says that SOA is forced into many applications where its really not appropriate.  I agree.  He also talks about Csla and SOA:
http://www.lhotka.net/weblog/CategoryView,category,Service-Oriented.aspx.  Additionally, he's posted  here on the forum several times.

Csla offers much much more than mobile objects though; that's only one part of the framework, and you need not use it to get the other benefits.  Authorization and validation, as well as helping you to keep data access code to limited areas of the code are also great benefits, in addition to thinks as built in support for databinding, etc.

I can't comment on WSSF specificially, but basically you can have your web service built on top of Csla business objects; that would be your "UI" layer and clients of your service need not care. 

Andy

You can use CSLA for both the client to your service app, and the service app itself. The BO's in each may be very similar, but not identical.

You client BO's properties may map 1:1 to the data contract, but their metadata and state won't transfer, same on the service side.

I am not familiar with the WSSF, but the PTracker example does have an example of a simple service using CLSA BO's

You'll end up writing the Business Logic into both apps, since neither can trust the other, so why SOA?

SomeGuy

The overall plan, similar to that of CSLA, is to have all the business logic in a single location.  In my case I was planning on doing that in the business objects and thier respective mapper classes that are exposed via a web service. 

So I would not be coding business logic in multiple places.  Granted there would be 'some' business logic in the UI but that is mainly for performance.  Situations like doing some of the data validation on the client to save a round trip.  But that logic would be duplicated in the web service since the service interface layer represents a trust boundary and the web service assumes all data from the outside is malicious and can't be trusted.

I am still very early in evaluationg csla and part of the problem may be my lack of understanding of what CSLA is all about.

Thanks for the comment.

---

Building tomorrow's legacy applications today!

What are you trying to accomplish by trying to use a web service?  What kind of application UI are you bulding, rich or web based?

You're right about the trust boundary and the need to validate.  But depending on what your application(s) may look like, you may be using a web service because you can, not because you really need to.

Could you tell us more about your application architecture at a high level?  That will enable us to recommend things and how Csla may or may not fit.

CSLA is all about a rich, interactive user experience. It puts the business logic (validation, etc.) very close to the user/UI. Then to support scaling, and security, it uses the concept of mobile objects to move the BO to the server to be persisted. The same BO is used in both places and there is only 1 application which can be configured to run as 1-tier, 2-tier, or 3-tier by just changing the configuration files.

If you need to open up your system to 3rd party applications, then SOA is it, otherwise you are going to write 2 applications that are going to have the same, or at least similar business layer.

SomeGuy

 

Actually we are trying to develop an applicatioin that is sort of UI agnostic and exposes functionality without any real concern for 'what' is using it.  So if a user is authenticated I don't care if they are making a timesheet entry from a phone, a browser, a smart client, or from a business partner's timekeeping program.

The real push behind this is to support publishing functionality vice publishing screens.  The software is a business intelligence system and a major design consideration is making it easy for business partners (and various devices) to interact with the system.

I liked the patterns and practices web service software facotry because it supported publishing interfaces and not the actual objects.  So our proprietary 'stuff' would never cross that service interface boundary.  The client would use the proxy to communicate back to the server via WCF.

You can check out the web service software factory here if you are curious. http://msdn.microsoft.com/en-us/library/cc487895.aspx

---

Building tomorrow's legacy applications today!

Hmm.. that doesn't sound like anything extra-ordinary.  Csla based objects don't care what uses them, and they are designed to be used from many "UIs."  UI being anything that interacts with the business layer to execute a use case.

That said, your business partners would probaby use your web service, which in turn would use Csla based objects.  Internally, there's no need for that, so you can build UIs that use those same Csla object directly.... that is assuming that everyone is running off of the same use cases.  Csla bsed objects exist to fulfill specific use cases.  So if the same use case applies equally to your business partners as your internal staff's mobile phone, they can all directly use the objects which fulfill that use case. 

If you haven't already, open up the PTracker sample tha comes with Csla.  There's one PTracker.Library, which has the business objects, and there are many UIs.  One built onWpf, one on WinForms, on on Asp.net and one that is a web service.

Andy

Andy,

Thanks again for the comments.

Like I said earlier I am still pretty early in evaluating framework options.  I have reviewed the what is csla and a few other articles.  I am still at the point where I am trying to wrap my mind around where csla will exist in my architecture and what it's responsibilities are. 

I'll be sure to check out that PTracker demo. 

To be honest I have not even downloaded CSLA yet, I was first wanting to gain, at the very least, a basic understanding of what it is all about. 

---

Building tomorrow's legacy applications today!

Generally speaking when it comes to SOA you can use CSLA in two places:

1. To create an application on the system edge (to interact with a real user)
2. To create a service application

The data portal itself is a message-based model and is essentially SOA, but that's usually not what people are interested in, nor does it sound like what you are after here.

CSLA is an excellent fit when building applications on the system edge. These applications are typically interactive and so all the data binding and business logic capabilities of CSLA work very well to help you create a rich user experience. And since CSLA doesn't care how your objects get their data, you can get/update the data by calling services just as easily as you can by calling stored procedures.

CSLA can be a good fit for building service applications (the actual services that comprise your overall system). Some services are little more than glorified stored procedures, and then CSLA isn't a great fit - but those are really lame services anyway and if that's all you've got then you probably shouldn't be doing SOA to start with... But services that do interesting work, that encapsulate business functionality and behavior (not just data access) must be written to implement all that business behavior. CSLA is one good option for building this type of service. As are various workflow and business rule engine products. Since service implementations are batch-mode, non-interactive, back-end code there are many great options dating back at least 30 years that all will work quite well if used properly. All the lessons of COBOL and FORTRAN totally apply in this space - seriously.

---

Rocky

Thanks to everyone for the great comments.   As far as SOA goes I believe I may be confusing a buzz word (SOA) for the concept of clean seperation between user interface / work flow logic, business rules / logic and data access.

The application architecture whitepapers that the microsoft patterns and practices group puts out suggests that a service interface layer is prudent whenever you begin to add that second user interface.  Following that guidance is what led me down the road to SOA via the patterns and practices web service software factory.

I wish I had found this framework two months ago, to draw in a different perspective on things. As I struggled through designing things like fine grained (object and field level) access control I was surprised at the lack of guidance out there. 

MSDN seemed to provide a single option; using role bassed access control in the web.config and that's that.  Anyhow I was surprised to see so many of the things on my own to-do list appearing in the feature list of this framework.

I am certainly taking a step back for a moment and am referring back to the underlying project goals of a scalable design that will support a variety of clients connecting in a variety of ways.

---

Building tomorrow's legacy applications today!

---

Rocky

I have been doing software development long enough to recognize the need for a solid framework to build on.  I have built many a small / medium sized system from *scratch* and they end up being pretty costly because of all the plumbing work involved and the slight variations in each project when I go back to do maintenance.

To reduce costs and remain competitive I needed to find ways to deliver the same functionality in less time which equates to a cheaper price.  My initial cut on this was, "I'll build a framework and write code generator templates that conform to the framework." Well I discovered pretty quickly that building that framework is really hard and incurrs it's own costs.  I have to dedicate time to the framework which is time I am not out making money and I won't be able to recoupe those costs for 2-3 (or more?)projects that use that framework and that is assuming I get the framework right!

This effort has been a real lesson.  I purchased a used copy of your book on amazon but after two days of waiting my patience wore out so I ordered the eBook from APress.  I haven't had a chance to read much, but the stuff I have seen seems like it was plucked directly from my own framework requirments.  I had the what but not the how.  I'm encouraged with what I have seen so far and am hopeful that this framework will give me that competitive advantage I was hoping to create with my own framework.

---

Building tomorrow's legacy applications today!