CAB Architecture and Conventions

Topics: CAB & Smart Client Software Factory
May 28, 2006 at 10:46 AM
originally posted by: derekgreer

I’ve been following the Microsoft Patterns & Practices document “Application Architecture for .Net: Designing Applications and Services” (available at ) for a application I’ve been developing over the past year (initially for the Web, but with future plans for a Smart Client implementation) and really like the conventions and layers presented in the document. For those who haven’t read the document, the layers presented are the User Interface Layer (consisting of UI Components), the User Interface Process Layer (consisting of UIP Components such as a MVC/MVP controller), the Business Layer (consisting of Service Interfaces, Business Workflows, Business Components, and Business Entities), and the Data Access Layer (consisting of Data Access Logic Components and Service Agents). Following these conventions, all of my business and data access components are completely UI and MVC implementation agnostic and my thoughts were that I would be able to reuse much of my code for a Windows implementation.

Upon my initial evaluation of the CAB, it appears that the designers took a different route for some of their naming conventions and programming model presented in the QuickStarts which I feel is less organized and layered than the above mentioned document prescribes. Rather than a clear separation between the UI, UIP, and Business Layer concerns, the CAB bundles all these components into a “WorkItem” which is in turn part of a larger “Module” assembly. I generally prefer to follow the recommended guidelines for a particular paradigm of development (i.e. “When in Rome …”), but bundling all the controls and business logic into the same assembly doesn’t lend itself very well to the reuse of these components.

My thoughts were that I could expose all of my existing business logic from the “Services”, and still follow a strict SoC organization for my existing components, but thought I’d ask if there were any recommendations in this regard. Thanks.
Jun 27, 2006 at 10:20 AM
originally posted by: derekgreer

Just to follow up on this, I just started looking at the reference implementation (SCBAT) and looking at the "Control Flow View" in the help file, the UML diagram indicates that the "AvailableAppraisalsViewPresenter" makes calls directly on the "AppraisalManagementServiceAgent". This indicates that any business logic involved in this use case would be contained directly in the Presenter which would tightly couple the business logic to this particular presentation approach (i.e. there is no reusable API which exercises the service agent apart from the CAB architecture). Of course, most using the CAB architecture may not be looking to reuse their code in other non-CAB applications, but with the rich level of abstraction which appears everywhere else in the reference implementation I’m surprised this aspect wasn’t considered.

Can anyone provide an explanation as to why the Quick Starts and the reference implementation aren’t using a true set of “Business Components” and “Business Workflow” components to abstract the business logic from the CAB components? In my opinion, the CAB reference implementation and examples should be guiding people toward developing a set of controllers/presenters which interact with a set of business workflow/business components which in turn interact with a set of data access logic components/service agents which would be consistent with the “Application Architecture for .NET: Designing Applications and Services” document. Any one else out there of like mind?
Dec 1, 2006 at 6:44 AM
originally posted by: mklapp


I am looking at some of the same issues you are. I have used the 3-tier architecture for quite some time (well or poorly). I like what the CAB provides. In my case, incremental development and configurable job descriptions are the good reasons I have for going composite. But Where should my Data Access Layer go? My first thought was to stick it all in the shell but I soon figured that would defeat the purpose of the CAB by making the modules dependent on that particular shell and limiting their reusability.

Currently I am considering a separate DAL class/DLL for each module. I have considered setting up the DALs as Services, but am not yet confident that is a useful direction.
Dec 1, 2006 at 7:15 AM
originally posted by: matiaswoloski

Having a service is the way to go. Services will belong to modules. Think about them as providers of any kind of functionallity. Make sure they have the correct interface. For instance

public interface IOrderService {
List<Order> GetOrders();
Order GetOrder( Guid id );

Then your implementation of this interface will go to the database right now, but in the future you could go to WCF by changing the implementation:

WorkItem.Services.AddNew<SqlOrderService, IOrderService>();

You realize that a distributed architecture might work better, then:

WorkItem.Services.AddNew<ProxyOrderService, IOrderService>();

You always works against the interface, so implementation does not matter.