Use Case Controller - JoeFallon1

Use Case Controller - JoeFallon1

Old forum URL: forums.lhotka.net/forums/t/6841.aspx


tna55 posted on Thursday, April 23, 2009

Hi Joe,

This question is for Joe really but anyone can contribute if  they like.

Joe has mentioned about UCC, objects that encapsulate other objects for a particular use case. I have a question related to that basically.

Does the UCC object expose properties (get/set) to UI which forwards the calls to encapsulated objects or do you expose the encapsulated objects as properties and UI bind/work with them directly?

e.g.

UC.Object.Property = someValue

or

UC.Property - someValue

where Property will do something like Object.Property = someValue

I really like the idea of UCC but it would help if you could describe its working a bit including things like data binding with it etc.

Help much appreciated

Tahir

JoeFallon1 replied on Thursday, April 23, 2009

You can do whatever you want.

I happen to expose the contained BO as described in your first example.

UC.Object.Property.

The "Object" property in the UC is ReadOnly so the user can only interact with the provided object - and NOT be able to replace it. The object itself has read/write properties as required.

I have a large Web app and do not use databinding extensively (at least not as shown in any of Rocky's examples.)

These UCC objects are extremely useful on complex screens and for complex interactions and workflows because they have access to all of the required data for that use case/workflow.

e.g. Filling out an Order or an Invoice requires alot of information and the top level UCC object gathers it all and co-ordinates it.

HTH
Joe

tna55 replied on Thursday, April 23, 2009

Hi Jeo,

Thanks for the reply, it was helpful.

The UCC is a very good idea. I used to create a Facade for a use case, which is similar concept however I think UCC is better because it forces to create a Use Case driven design and improve the maintainability and re-use of objects. The objects contained in the UCC can be re-used in different use cases without plumbing in of use-case based code.

Few questions:

Exposing the objects as readonly properties is fine. I am just wondering how you avoid the UI (or UI developer) to call the Save or any other method on the object itself? I am assuming that calls to the encapsulated objects should go through UCC, is that right?

Similarly how about validation? In case of UC.Object.Property the validation will be invoked in the Object. How do you pass that back to UCCs broken rules?

Tahir

JoeFallon1 replied on Friday, April 24, 2009

Tahir,

In general calls to encapsulated objects should most likely go through the UCC. I won't say always.

Maybe the UCC contains an Invoice and all you need to know is if the Invoice IsValid and can be saved. The rest of the UCC may have been for screen support.

I have posted many times on validation. My root BO may contain other BOs in that case my list of broken rules for the UCC are all the rules for it plus all the rules for each child. Rocky and others disagree with this approach and do not cascade the calls down to child BOs. For my Web UI it makes sense that the user can see the list of ALL problems and then address them when they go back to edit. YMMV.

So if I call mUCC.IsValid it will have a list of all broken rules.

Joe

tna55 replied on Saturday, April 25, 2009

Joe,

Thanks for the reply. Few more follow up questions if you don't mind please.

Calls to encapsulated objects should go through the UCC, most of the time, that is fine really. However, you do you implement this as there can be two ways to do this.

1) UCC has a property InvoiceDate (Date), which in its get/set call Invoice.InvoiceDate. Client calls UCC.InvoiceDate = someValue.

2) UCC has the encapsulated exposed as property and client calls UCC.Invoice.InvoiceDate = someValue.

In case of windows application (or WPF) is the client form bound to UCC or to UCC.Invoice object?

Tahir

Killian35 replied on Saturday, April 25, 2009

Hello,

I also have a couple questions for you, Joe, if you don't mind.

1.
Where do you keep your use-case controllers? In the web app or the business library?

2. If you keep them in the web app, are they aware of the web UI controls? Or do you just use the code-behind page to flow events and information between the UI controls and the controllers?

Thanks,
Kelly

JoeFallon1 replied on Wednesday, April 29, 2009

1. The UCC objects are just CSLA root level BOs. So they are in the Business class library.

2. They are not in the web app. (They are not defined there - they are obviously used there.)

Please do not confuse these UCC objects with any of the new fancy buzz words floating around for Model View Controlller or anything like that!

They are unrelated concepts (at least in my mind.) It is just a name for a top level BO to handle a Use Case in a business app. As I said earlier, I used to call it a Unit Of Work - but apparently that has other meanings too! However I still name them things like InvoiceUOW out of habit.

Joe

Tom_W replied on Thursday, April 30, 2009

Apologies for the slight threadjack - this sounds like a really interesting approach and one that I have pondered on in the past.  Could somebody point me at the original source material being discussed here?

Thanks, Tom

JoeFallon1 replied on Thursday, April 30, 2009

Tom,
There is no original source material.
I have been building a large web app with CSLA.Net since 2003 or 2004 when it first came out. I needed to do these same kinds of things back then and based on comments from other forum users decided this methodology would work for me. I have discussed it many times over the years and people seem interested in hearing about it.

A lot of times you will read that BOs should be designed around behavior and not data. I am sure that is the correct model. But I use Codesmith templates to generate BOs from my database tables so they all "start out" looking like a table. I may add a few extra properties to a BO (I borrow fields from other tables and expose them as read only values) - or the root BO could contain a child list with child objects in that list. These kinds of self contained BOs are clean and can be easily saved back to the database.

By having a Use Case Controller root level BO I can "gather up" various BOs to support the use case and use them without worrying about "cross contamination". I can re-use some of the BOs in other UCC objects if necessary. The UCC object can also gather metadata from the DB and load the BOs with it to "prefill" it with data. Or to assign labels to the screen based on user definitions.

Calling Save on the UCC object sends it through the DataPortal but once inside you may only call save on one of the simpler BOs - or you could have complex interactions between BOs and commit them all in one shot.

This pattern has worked well for me for over 5 years now so I keep promoting it.

YMMV
Joe

Tom_W replied on Thursday, April 30, 2009

Hi Joe

Thanks for taking the time to respond in detail.  That's a really interesting approach.  The area where it really interests me is in handling complex cross object interactions. 

For example, we write ERP software that deals in part with stock management.  When the user wants to pick the elements of the order for delivery the system will tell the user what stock lots to pick from based on a number of criteria (typically first in first out, but not always).  At the same time it will create allocations to prevent anyone else from picking the same stock or moving it.

Without getting into too much detail, this involves a lot of fairly complex logic that is currently wrapped up in a big stored procedure that writes and updates records in half a dozen or so tables.  The benefits of the stored procedure approach are obvious, it's fast and it's optimised.  But, the SPs are a maintenance nightmare from the point of view that business logic is now hidden on the DB server and debugging through stored procedures is still a PITA.  It also means we are replicating business rules in the stored procedures.

What I would prefer to do is pull all of this logic into objects/classes that represent workflow, whilst still maintaining a single transaction to wrap the individual simpler business object saves.  It strikes me that UCC objects could be a neat solution to this.

In truth this is an area where my OO knowledge fails a bit (as is no doubt clear).  The other area of interest for all of this that Rocky's latest book has introduced me to is the idea of using WorkFlows to wrap up these types of cross-object interactions.  Have you looked at these at all?

Thanks again, Tom

JoeFallon1 replied on Friday, May 01, 2009

Tom,
I have not looked in to WF yet. But my app has "workflow" of its own. Mostly just state changes of an object as it moves through a process. (Recorded, Validated, 2nd Validation, Coded, Approved, Exported - stuff like that.)

Moving the buiness logic for the complex save across multiple tables to a single BO is a good idea. One way to handle it is to create a Command object and pass it the various parameters and let it open a transaction (tr) and make the various CRUD statements inside of it. This way the same object could be re-used from another part of the app that needs to make the same call.

For example in my app I may need to "delete a requisition". Sounds easy. Involves something like 12 separate SQL statements done in a specific sequence. But I can re-use this command object in many places that need to do the delete simply by passing it the reqNumber.

If your operation takes "too many parameters" then consolidating the logic in the UOW will also work. That way it has access to all the data in the use case (various lists, and BOs etc.)

Something to consider.
Joe

Tom_W replied on Friday, May 01, 2009

Again, many thanks and much appreciated, that is definitely food for thought.

Finding a really robust solution to this type of complex workflow has been something of a pet project of mine for many a year!

JoeFallon1 replied on Wednesday, April 29, 2009

I do not have a WPF or Winforms app and do not use DataBinding. I imagine that it works fine but do not really know.

In my Web app I fetch the UCC object and may have a page level variable for the contained object and just deal with that variable for reading and writing data.
Joe

DancesWithBamboo replied on Thursday, September 03, 2009

Sorry to resurrect an ancient thread; but I really like this discussion and am very much interested in designing this way using UnitofWork.  I have a couple questions about how to implement it in the 3.7 framework / WPF though:

I'm trying to get my head around how you set up the UoW from a parent-child and dataportal perspective.  I don't see how you can have the UoW be a BusinessBase object and have children that are ReadOnlyListBase (drop-down values) defined in managed properties.  When you call "Save" on the UoW it dies because ReadOnly objects don't have a save. 

Or are you calling Save on the children?  If you do that, then how do you define them in the parent UoW such that you CAN call save since normally children can't be saved directly.

If the children are saved seperately, where do you re-hook any events between objects as the new instances come back from the DP?

Or is this whole concept "not as good" in the bound up world of WPF as it is in the Web world?

Any help would be greatly appreciated; especially from Joe.

Cheers,
Glen

jasonlaw replied on Thursday, September 03, 2009

I am too very interested in knowing how this concept works in WPF, or even Silverlight.
Would be very much appreciated if there is any simple example, may be just modified from Project Tracker?

I think this is a very good idea indeed.

Thanks.

JoeFallon1 replied on Friday, September 04, 2009

1. I have not switched to Managed Properties yet.

2. I have not tried WPF or Silverlight yet.

3. The use case controller or Unit Of Work BO (UOW) *contains* other Business Objects. Nothing says those BOs have to Child objects. In fact one of my most complex UOW contains a Root BO. When you Create the UOW the Root BO property is not set. When you later call one of many methods on the UOW it creates the internal root BO according to the use case required.

4. When you call Save on the UOW it merely gets you to the other side of the Data portal. What you do there is entirely up to you. I start a transaction and process various BOs as needed and perform other cleanup functions related to the saving of the Root BO. For example if the Order moved from the Hold file to become a real order then I save the Order and remove the Hold file records.

HTH
Joe

 

Copyright (c) Marimer LLC