What go where?

Topics: CAB & Smart Client Software Factory
Sep 30, 2006 at 12:32 AM
originally posted by: cjwik

I have tried to sort all this out and starting to get a good picture of it, but still there is something missing in my knowleger about this.

Question 1

I have:
OcrModule - create, modify, delete, OcrDocuments
In this module i have:
OcrView - to look at the OcrDocument(smarpart).

One toolbar (Ocr) with a new document, scan, image from file.... buttons.

Object OcrDocuement, with a collection for the images.

In the module (load) I add the toolbar to the main shell.
I make an event for click new button on the toolbar.

Where do i listen to the event click new document. In the module, or present class for the OcrView?

****
Question 2

I come from the "old" n-layer thinking.

I have a Data layer.
And a Bizz layer.

Where do a talk to the Bizz layer? Module, presenter? Do I make a service outof the Bizz layer? At the moment the Bizz layer is a simple .dll but some of the Bizz will be WebService in the future.

Some input how you have designed it would make me happy:)

CJ
Sep 30, 2006 at 4:15 AM
originally posted by: askew

1. You can subscribe to the button click events anywhere, I choose the Presenter classes, unless the message is 'module-wide', then I use the Module (or ModuleController with SCSF).

2. Same with the business layer, I'd normally talk to them in the Presenters unless the rule pertains to the entire module. I think it is proper to make these Services.
Sep 30, 2006 at 12:03 PM
originally posted by: ChrisHolmes

I love these architecture questions. There's so many ways to skin a cat :-)

-------------------------------------
I come from the "old" n-layer thinking.

I have a Data layer.
And a Bizz layer.

Where do a talk to the Bizz layer? Module, presenter? Do I make a service outof the Bizz layer? At the moment the Bizz layer is a simple .dll but some of the Bizz will be WebService in the future.
-------------------------------------

This is where it helps to define responsibilities for certain pieces of code, and then stick to that design. In my particular case, I decided that WorkItems were going to be responsible for:

(1) Instantiating Views & Presenters, showing them in appropriate Workspaces, and managing the lifetime of those objects.
(2) Instantiating services and adding them to the Service collection when necessary.
(3) Responding to Commands or EventBroker Events that relate to changing Views (ex: a toolstrip button that causes a different WorkItem to show a particular View)

Presenters are responsible for (nearly) everything else. They respond to View events, use the DI framework to fetch references to Services that they need. So in answer to the first question, I would always have the Presenter respond to Commands, unless the Command caused a new View to show, or to show an old View (basically changing the UI layout in some way).

The only thing our presenters don't really do too much of us mess with the Business layer. We leave that for Manager objects to handle.

In our particular case, since we were using an O/R mapper, we decided to go away from the Domain Model (objects with business logic embedded in them) and move toward a Manager Model. Manager objects get references to the Service Layer (really a Remote Facade on the Data layer, injected when the manager object is created) and use that to make calls to the Data layer.

The Service layer methods preassemble the O/R objects and pass those back to the Manager, which then exposes it's data via methods and domain specific objects (we like this approach because it helped us with databinding). The manager can then query the data layer for whatever it needs, and it can instantiate any Business policies/strategies it might also need (or WorkFlows), some of which may be stored in the Data layer (i.e. WF RuleSets or a persisted WorkFlow). Presenters are then charged with instantiating these Manager objects, injecting them with references to the Service layer and making calls against the Manager to get the data they need.

Our Presenters do a lot of the "heavy lifting" in our apps (along with the Manager objects that do the heavy processing of data). We keep our Views light - they have absolutely no business logic in them, or presenter logic; they do not receive any Commands or Events, they just make calls to and from the Presenter.

So there's one take on the whole thing :-)
Oct 6, 2006 at 5:49 PM
originally posted by: OlofEdlund

Thanks Chris.

This post made it "click" for me. I'm still not completely clear on everything but I feel that I'm getting close to really "getting it".