CSLA.Net and Patterns and Practices software factories integration

justin.fisher posted on Tuesday, May 06, 2008

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?

ajj3085 replied on Tuesday, May 06, 2008

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

justin.fisher replied on Wednesday, May 07, 2008

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.

ajj3085 replied on Wednesday, May 07, 2008

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

smiley riley replied on Friday, May 09, 2008

First of I think the idea behind csla is a good one. Unfortunately for me it does not deliver, and I will now explain why, just picking up on the n-tier for starts. I have just picked up an application created using csla, and need to make some quick changes before I can CTRL-A and build an enterprise version. Having come from a campany with a team of good developers we created our own framework over a period of years following proper n-tier and gang of four practices.

Any business object which has functionality in property setters will never work over webservices without loosing all that functionality or compromising the whole integrity of webservices. A bit like exposing Datasets to the world over SOAP, do not do it. So if I use CSLA objects over SOAP using my WSDL as the contract how when I pass that object back do I know it is Dirty or is New or is to be archived/deleted? All of a sudden my 'Save Object' become Update, Add, Delete and my front end gets more BLL than it needs to have! In my opinion it does anyway! Not a biggie just replace all the property setter stuff with a prepopulated set of underlying values and a model base that uses a virtual method that uses reflection to determine the values are equal or not as the case maybe when they come back. Override it in the child class should reflection be too slow. Yes you need to know about Generics too.

DataProvider. This is the biggie and the one that infuriates me more than anything. Having a DAL that uses the specific DataAdapter referenced in it does not satisfy Abstraction from the database. A switch statement for every update, select, delete statement with an entry for each DB type is flawed. The DAL should only know about the System.Data abstractions/interfaces, and for this you would need a DataProvider with specifics for differing database types, this does not exist in any form I am aware of in csla.

IMHO read Craig Larman 'Applying UML and Patterns' and once you have a grasp of the principles in that book, then take a look at CSLA. You will then understand the principles behind it and whether you think it will save you the time you think it is going to.

ajj3085 replied on Friday, May 09, 2008

smiley:
Any business object which has functionality in property setters will never work over webservices without loosing all that functionality or compromising the whole integrity of webservices. A bit like exposing Datasets to the world over SOAP, do not do it. So if I use CSLA objects over SOAP using my WSDL as the contract how when I pass that object back do I know it is Dirty or is New or is to be archived/deleted?

The answer is that you DON'T send Csla objects out over a web services interface to be consumed directly. Rocky will tell you that's a bad idea, as well as anyone else here. What you should be doing is building your web service, complete with DTOs that you DO expose. You populate the DTO with data from the business object and send it on it's way. The client sends a DTO back, you get your BO again, update it with the data in the DTO and check business rules (you check the ValidationRules property). If the BO is fine, you report that back. If not you send an error message back. But the client of the web service never sees anything to do with Csla. That is hidden. The web service provides method calls that fulfill use cases, and those method calls are proxies to Csla objects. At least that's my understand of building a web service with Csla.

HTH
andy

smiley riley replied on Monday, May 12, 2008

Hi Andy,

Yes yes I understand this, but this is again flawed for the reasons I gave above. You have then created two sets of models one a DTO model the other a business Model if you like. What is the difference between these objects, excluding the obvious business functions methods in the Business Model. I would be suprised if there was any.

The advantage of Business Model over DTO model it that in essence and correct me if I am wrong, because all the methods are included with the data GRASP states we have 'Information Expert' we also have High Cohesion through Communicational Cohesion. That is the principle anyway.

My argument is this.

An object to store data has a functional task of storing data and nothing more hence a Model object should contain no functionality other than that to support in memory datastorage, what you would call a DTO. All tasks for that model should be transferable accross barriers, including Soap. Which basically means Getters and setters with no functionality. The business logic component has the functional task of carrying out functional requirements not storing data. So seperating these two functions looses you information expert granted, However you have gained low coupling, and high cohesion (Logical, functional and sequential) You do not have to write a DTO to BO 'Data Access Layer' because the SOAP standard dictates that for you and takes all the work out of it for you. You start to look at your applications as applications that carry out task and not applications that store data, this also aids testing, and links nicely in to UML and use cases.

I find it strange to see the concept of DTO's used at a Web service level but not at the Data Access Level. Unless they are of course???

ajj3085 replied on Monday, May 12, 2008

smiley:
Yes yes I understand this, but this is again flawed for the reasons I gave above. You have then created two sets of models one a DTO model the other a business Model if you like. What is the difference between these objects, excluding the obvious business functions methods in the Business Model. I would be suprised if there was any.

I'm not sure I totally understand what you're getting at so this might not answer the question. The BO has the responsiblity of enforcing business rules for a use case. A DTO has the responsibility to contain data, so it will match whatever shape the data needs to be in. The business object will be modeled by it's behaviors; any data it has are there to help it fulfill the use case.

smiley:
An object to store data has a functional task of storing data and nothing more hence a Model object should contain no functionality other than that to support in memory datastorage, what you would call a DTO. All tasks for that model should be transferable accross barriers, including Soap. Which basically means Getters and setters with no functionality. The business logic component has the functional task of carrying out functional requirements not storing data. So seperating these two functions looses you information expert granted, However you have gained low coupling, and high cohesion (Logical, functional and sequential) You do not have to write a DTO to BO 'Data Access Layer' because the SOAP standard dictates that for you and takes all the work out of it for you. You start to look at your applications as applications that carry out task and not applications that store data, this also aids testing, and links nicely in to UML and use cases.

Well the reason you transfer a DTO out of the web service and not a BO is because you're crossing a trust boundary. You can't trust anything outside the web service, nor do you want to couple the client of the web service to your BO. You should be able to change your business logic without forcing clients to update their calls. Ideally, your web service can still fulfill it's use case, but that may not be possible to due to new rules.

As far as the BO talking to the data source, it doesn't really matter how the BO does that. If you want to use SOAP, you could. I think it's better to either talk to the db directly, or using some binary protocol. But you may still have DTOs here; Linq to Sql classes can be considered DTOs.

smiley:
I find it strange to see the concept of DTO's used at a Web service level but not at the Data Access Level. Unless they are of course???

It depends on what you're doing. Csla doesn't force you to use DTOs, you could use Ado.Net, or you could use anything else. I would say pick the simpliest one possible though.

justin.fisher replied on Friday, May 09, 2008

I have Craig Larman's book, I was impressed with the fact that Martin Fowler recommended it as a primer for OO design. I have been doing OO desgin for a few years now and I am familar with most of it's basic tenants.

The unfortunate part of my situation is that I don't have legions of developers and years of time on overhead to develop a framework. I believe that I initially underestimated the scope of doing something like that.

I am by no means an expert on CSLA, actually I am still in an evaluation mode. I have been looking into this framework in my 'spare' time both for feasability for my own use and looking for ideas that I could use to salvage my own framework I have started on a few months ago.

As far as the data provider I think this would be a great place for the patterns and practices data access block available from the MS P&P team. With that you code against a generalized database which uses a factory to retrieve an instance of a specific type of database (sql, oracle, ?). I saw where the framwork creates a safedatareader and I'm not sure if that could be incorporated with that data access block.

Thanks for the comments.

ajj3085 replied on Friday, May 09, 2008

Justin,

To me, that's one of the great things about Csla. The only rule when it comes to data access is that you MUST limit it to the DataPortal_XYZ methods and any helper methods called by a DataPortal_XYZ method should not be called unless you are "in" the data portal.

Otherwise, do whatever you like in the DataPortal_XYZ methods. You can use Linq to whatever, Ado.Net directly, NHibernate, or the DAAB.

Regarding the safe data reader, there's no requirement to use it. It just helps if you're using the SmartDate type to store date time data which may be empty. Even if you use SmartDate, yo don't need the SafeDataReader. I never use it because I never use Ado.Net directly; I use either my custom DAL which is similar (but much less feature rich) to NHiberate, or anything new I'm using Linq to Sql.

As long as you remember that code re-use is not a goal in and of itself, and that you design objects to fit use cases, NOT data, you'll do just fine with Csla.

Andy

RockfordLhotka replied on Monday, May 12, 2008

smiley riley:
I always tranfer DateTime fields as doubles.

Certainly you should not try to use SmartDate in a DTO to/from a service or a database. In those cases you need to pass date values in some form that is accepted on both sides of the conversation.

And if your application does use the concept of an 'empty' date then both sides need to agree on what that means too - often string.Empty, null or some specific date value (typically a very old one).

If you are using .NET 3.5 you might look at the DateTimeOffset type. The primary issue people run into when transferring date values is time zone translation. And DateTimeOffset is supposed to help with this issue (though I haven't really dug into to see if it solves anything).

smiley riley replied on Monday, May 12, 2008

Justin,

I don't confess to be an OO expert by any means my level is probably like your own, but as developers we all know there is application of all these theories and you can pick and take these as you choose and what suits you. IMHO when it comes down to it if you are uber good and can deliver good software time and time again and at the same time not follow any standards, then who is anyone to say you are wrong. It maybe tricky to take over the code but thats why Microsoft created Ctrl & A is it not. ;-)

You are spending time reading csla, and my point is if you have the OO knowlege I dont' think it would take you any longer creating your own base classes for DB, MSMQ DAL standards etc. Just create your common components with flexibility so new functionality can be brought on later. Most people have some sort of DATA Helper class (if not adapt microsofts old one in petshop) simple but effective. An easy way is to take that class create an abstract version of it exposing Interfaces and Abstract types (System.Data.common) rather than say SQLCient types. When you need to add oracle inherit the base class and add any functionality required. Don't forget to check the DbType Mappings and create functions to get around the lack of compliance between database vendors and the base DbType. Probably the most painful part.

It is by no way clean as like I said above DB vendors did not seem to follow a Type Pattern so work has to be done around this for Bool, Blobs Clobs etc but once the base class is written you can write a new database implementation using the base implementation in a day, and if you move from SQL to Oracle it will only be the Provider you need to change.

Unfortunately, I have not had time to look at the application blocks but maybe one day I will get time.

Paul

SomeGuy replied on Wednesday, May 07, 2008

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

justin.fisher replied on Wednesday, May 07, 2008

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.

justin.fisher replied on Wednesday, May 07, 2008

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

ajj3085 replied on Wednesday, May 07, 2008

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

RockfordLhotka replied on Wednesday, May 07, 2008

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

To create an application on the system edge (to interact with a real user)
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.

justin.fisher replied on Thursday, May 08, 2008

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.

RockfordLhotka replied on Thursday, May 08, 2008

Ahh yes, the “one technique fits all” quotes… They just follow whatever trend is popular at the time – SOA at the moment (though I think it is starting to fade now thankfully).

The broader reality is that you need some way to cleanly separate the UI and business layers in any app. A service interface is one technique, with strengths and weaknesses. Personally I think the weaknesses are pretty big and typically outweigh the benefits.

Data binding provides a set of interfaces that form clean separation. They also have a set of strengths and weaknesses. If you have to implement the data binding interfaces yourself then I’d say that the weakness is complexity and that it could easily outweigh the benefits. But if you don’t have to implement them yourself (because you use something like a typed dataset or CSLA .NET) then the benefits are pretty awesome and the cost is quite low.

And there are other techniques and design patterns you could use.

But ultimately the key to success is that clean separation between the UI and business layers (which doesn’t have to be a physical network boundary – just a logical boundary). Chapter 1 of my book provides pretty good coverage of this, along with other important concepts.

Rocky

justin.fisher replied on Thursday, May 08, 2008

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.

zinovate replied on Thursday, May 08, 2008

Given your experience, you'll love Expert Biz Object 2005. It's a great read. I'm sure that you'll see Rocky go through allot of the problems that you faced over the years. I sure did. The ebooks help fill in the gaps on the more current changes, especially WCF.

CSLA will give you a leg up for sure.

The fact that Rocky is working hard on Silverlight support is too awesome. I can't wait to start playing with it.

SomeGuy replied on Wednesday, May 07, 2008

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