client / application server

martin_s posted on Friday, April 03, 2009

Sorry for the newbie style questions - I feel I shall be asking more of these :)

I come from a Delphi background working on a large system with our own in-house framework so I'm currently in that mindset and trying to make the transition as we being R&D to prepare for a large migration over to .NET

The application server currently comprises COM+ components and the customer is keen to keep this multi-tier architecture which will mean a WCF application server and winform clients. 

In csla on the client side I'm assuming calling the save methods to persist the data will serialize the objects and send them via WCF to the application server where they will be deserialized back into objects and persisted -  the same when loading (in reverse of course).  Does this mean client classes and server classes (as we currently have).  The client classes just know how to serialize and call the server, the server calls the data access layer to persist the data from the populated objects.

In our current system we have request stacking (we term a request as any load/save method calls to an object).  We can issue Object.LoadByKey(...) etc on several (unlinked) objects, then issue a supplierclient.execute which will dispatch the stacked up requests to the application server where the class factory deals with the requests, creates and populates the objects, serializes the data and returns it to the client in one single network trip.  Is there any equivalent, single trip, multiple requests in csla.

In our current system we have lots of application server business methods - such as PlaceProductOnHold(...) etc.  These methods will use many objects to implement the business rules resulting in several objects being updated and persisted to the database (in a single MSDTC transaction).  The client class has a PlaceProductOnHold method, which simply calls the server where the business rules are implemented and receives a response.  Is this something that is appropriate to the csla framework.

I'm trying to work out what adjustments I need to make in my thinking - Never easy when you've put so much commitment into an existing project and designed your own framework.

JoeFallon1 replied on Saturday, April 04, 2009

Those are a lot of good questions.

The first and best piece of advice is to buy the 2008 book (VB or C#) and sit down and read the whole thing. It is the best book on distributed architecture you will ever read. And you will instantly recognize Rocky's easy going style in explaining very difficult concepts.

Your initial assumption is correct. A Business Object (BO) can be serialized and deserialized to/from an app server. The next part of your statement is not correct. In CSLA it is the exact same BO which appears on both sides. No client classes, no server clases. Just 1 BO class. This is what Rocky defines as a Mobile Object. It moves itself across the wire and is self contained in terms of data and validation and authorization rules.

The CSLA framework takes care of contacting the app server if required. If you want to run without one it is just a different setting in the config file.

If you have a root level BO it can contain many other BOs. So a request across the wire to populate this root will cause all its children to get populated too. Then the whole object graph is sent back. I call this a Use Case Controller object - it is a standard root BO which contains all the other BOs to perform a use case. e.g. Enter a new invoice may require 5 BOs - they are all contained in the Invoice unit of work.

You cannot make a single request and get back multiple unrelated BOs. You can make 1 request per BO and get back each one.

App server methods can be "translated" to the CSLA CommandBase object. It can contain many other BOs if needed. You instantiate it client side - give it whatever parameters it needs (PO Number, Date Range, etc.) and call Execute to send it to the app server where it deserializes and calls DataPortal_Execute. In the execute method you do whatever needs to be done server side. You can even set flags and messages and the BO is returned to the client with that information intact so you can inform the user what happened.

HTH
Joe

martin_s replied on Sunday, April 05, 2009

Thanks for the reply.

C# 2008 Business Objects landed on my desk on friday, although where I'm going to find the time to read it all I don't know. 

Are there any code examples available which demonstrate the mobile objects model using WCF and how the config file is used to configure csla to perform its object persistance via an application server.

Its a shame that we cant stack requests in the framework and execute them in a single trip.  The customers network is a busy place and the fewer trips we have to make to the app server the better, which is why we designed our existing framework with this feature.

There are many instances where I can design parent/child relationships based on our database design, but in the applications there are cases where I would only want the parent to be loaded, and other cases where parent and child loading is required.  I'm assuming in parent only cases lazy loading of the child objects would handle this, but is there a way from the client app to specify load parent and children, or load parent only.

In our existing system we use raw ADO datasets for readonly data.  Mostly for report generation and grid displays where the data view is specific to a single application and usually relies on cross table joins to retrieve the data.  I can't see the benefit of using a BO in these instances. Is this a model which would be valid in a csla  

RockfordLhotka replied on Sunday, April 05, 2009

JoeFallon1:

You cannot make a single request and get back multiple unrelated BOs.

That's not entirely true. Joe is right, in that this shouldn't come up if you do good object modeling, but technically you can use a Command or ReadOnlyBase object as a "request object" that returns multiple unrelated objects in a single data portal call.

DocJames replied on Saturday, April 25, 2009

RockfordLhotka:

JoeFallon1:

You cannot make a single request and get back multiple unrelated BOs.

That's not entirely true. Joe is right, in that this shouldn't come up if you do good object modeling, but technically you can use a Command or ReadOnlyBase object as a "request object" that returns multiple unrelated objects in a single data portal call.

The same way you would use "Saving Multiple Root Objects" ( http://www.lhotka.net/cslanet/faq/(S(rm1rki45kyfvdk55hcxgjoj5))/SaveMultipleRootObjects.ashx ) you can Load multiple root object istead of saving them.

Jimmy

RockfordLhotka replied on Saturday, April 25, 2009

I think that even with good object modeling, you can easily envision
scenarios where it is more efficient to retrieve multiple root objects in a
single call to the app server.

There's another thread running now about use case "controller" objects (or
something like that) - which is really along this same line.

And using a ReadOnlyBase or Command object to go retrieve a set of root
objects is a fine thing in that case - I really don't know that it breaks
the object model as long as this "retriever object" has exactly one
responsibility: to retrieve these other objects.

Rocky