Web-Application Framework - Catharsis - part VI - Framework Architecture

Introduction

This article is the next step in Catharsis documented tutorial.  Catharsis is a web-application framework gathering best-practices, using ASP.NET MVC, NHibernate 2.1. All needed source code you can find on    

http://www.codeplex.com/Catharsis/

	No.	Chapter	No.	Chapter	No.	Chapter
	I	New solution	VI	CatharsisArchitecture	XI	Controller layer
	II	Home page observation	VII	Entity layer	XII	UI Web layer
	III	Roles and users	VIII	Data layer	XIII	Tracking, PAX design pattern
	IV	Localization, translations	IX	Business layer	XIV	Catharsis Dependency Injection (DI, IoC)
	V	Enter into Catharsis, new Entity	X	Model layer	XV	(Code Lists - undone)

Latest stories about Catharsis

Latest stories about the Catharsis framework you can find:

http://www.codeproject.com/KB/aspnet/catharsis_tutorial_01.aspx

David O'Sullivan will guide you through   

• the Catharsis guidance installation;   
• the Example observation  
• and extending the Example with new stuff (entity and its infrastructure)

Catharsis Architecture     

When you have just Entered into Catharsis, and did use the Catharsis.Guidance in the full strength, it is time to slow down. Catharsis is not based on code-generators, ‘smart’-designers etc. It only should help you to quickly start with needed skeleton for your new Entity object. 

Catharsis is based on a best practices gathering Architecture. There are really independent layers, which are responsible for specific, separated tasks. Their structure could be displayed as shown below.

(Catharsis Architecture)

Entity 

Catharsis uses OOP as much as web development allows. Therefore the Entity layer is the core of application. Entities have properties, owned entities (Subject has Address) or collections of entities (Order contains Products).  

To improve searching among Entities, each object provides its searching object as you'll see in the next chapters.  (Entity layer)

Common

The Common layer has two main jobs. Keep description of any object which can be used to handle Entities. And the best way are interfaces. Every Façade, Dao, Controller or Model must publish its interface in Common layer, because every upper layer works only against these descriptors – interfaces. (Controller has its IModel and IFacade instead of Model or Façade). To support such behavior Common provides factories, which are smart enough, to produce implementing-objects if you are asking for interfaces.

Catharsis evolved form SharpArchitecture (by Billy McCafferty). Billy has (among other tremendous things) introduced the breaking IoC model (Dependency Injection, Inversion of Control). It is based on a such simple .NET (C#) feature - attribute. Every interface, which you would like to be created via factory, must be decorated with attribute ConcreteType.

namespace Firm.Product.Common.Business.Clientage
{
    [ConcreteType("Firm.Product.Business.Clientage.SubjectFacade, Firm.Product.Business")]
    public interface ISubjectFacade: IFacade<Subject> {}
}

The string provided in constructor is the full-name and .dll of interface implementing class. I would say that this approach has Catharsis even improved. We'll examine it in next chapters.

The second main responsibility comes from the Common library 'position in the architecture'. Every upper layer can see what is published in Common, and so every provider takes place here. Among others you can find here ResourceManager, ApplicationRoles ... (and your own as well)

Data storage

This layer has only one responsibility – store entities. Nothing else! Nothing, just store. 

(I am still not sure if it is clear so: No store procedures, No triggers, No integration tasks or DTS… !) 

Data 

NHiberante, NHibernate, NHibernate, we bless you. There are people who still do not use NHibernate. The reason is clear, they do not know about NHibernate, or they are not allowed. Yes, in some companies the OpenSource is not good enough. 

There is a new tool, which is not OpenSource - MS Linq to Entities. Well it is not ORM tool anyway. If I will succeed and you'll understand the layers of Catharsis and the separation of concern – and if you will examine Linq to Entities (LtE) – you'll understand. In LtE every layer (existing in Catharsis) is mixed together and you cannot change it. I did believe that LtE could once replace Data layer in Catharsis, and take the response of getting and saving Entities into persistence. But it is just impossible. LtE is usurping every possible layer for itself, in one damn namespace.

Well, Catharsis is also OpenSource. So, if you'll be allowed to use Catharsis, you will be allowed to use NHibernate as well! ) 

And what is really important: Data layer will be responsible for only one simple task! Get Entities from or Set them to data-storage.  Nothing else.  (see Chapter VIII - Data layer)

Business  

From Catharsis point of view, this is the most important and crucial layer. You won't meet Business layer so usually and often, if you'd be examining other frameworks. I did even hear “… the business layer is only fairy tale, we apply rules on other tier … “. 

Business tier is the only place where all your ‘business-rules’ should take place and their evaluation might be done. 

Does object contain the not-null and not-empty property ‘Name’?  
 Then do check on a façade whenever add or edit is executed. 
Does user ask for deleting object? 
 Do not count on database relationship constraints, 
 do the check before you call Dao to delete entity!   

AOP

ASP.NET MVC also provides AOP (aspect-oriented-programming). It is as simple as it could be, but how powerful!. Just provide the filter attribute on intended action or controller, and the AOP will be called and evaluated. The nature of AOP is the ‘business rule’, and therefore they are the second responsibility of Business layer.   

AOP filters can not only do logging, authentication etc., but they can even inject information into Models! Even on Business tier the interfaces of IModels and IControllers are available! (see Chapter IX - Business layer) 

Business reuse

Business layer is described more detailed in Chapter IX - Business layer. What must be written right now: You'll enjoy to work on that layer. There is no (probably) web-application which does not need to exchange data with outside world. The most usual way is MS Excel, isn't it? Users want to upload their existing data into application or download 'reports' into sheets etc. 

You can create as many applications which will support your web-app in that way. Scheduled batches, importing wizards, extractors ... With Catharsis you are lucky-girl (guy), just call already created and used IFacade which will carefully provide checks on imported (or even extracted) data. If you'll admit this approach - that business rules must be applied only on the gateway (not in storage, nor on the UI) - you'll gain a lot...

Model 

Models are interfaces declaring only properties. They do not have methods. Implementers only serve as containers, which are filled by controllers and then displayed on View.

Catharsis is keeping the ‘per-request-controller’ pattern, which also means – new model instance for new controller instance. Models are not stored let’ say in session! They are created, filled, used and forgotten. 

Wonderful approach. It’s saving server memory (no waiting references in session and objects on heap). Ajax usage is simple. Even the Entity updating, after session is expired, is possible!

Despite of that fact, Catharsis stores some information (available via the Model properties) in session. Those are entity based 'search parameters' (current page number, filters, anchor targets...). For you is important, that what should be stored, is on next request restored and ready to use (change or apply as filters on resulting list view)
 

Controller 

Controller is the navigator. You are calling its actons, providing the form data, calling IFacades for storing or getting. Controller fills the IModel and when finished, passes its reference to the View. 

The essence is really only to process request data, and ask some IFacade for persisting them.

There are some Controller's bases, which do lot fo job for you:

WebController contains smart binder, which can bind culture based number or date strings into the Objets.  

Entity Controller extend this abilities with implemented CRUD operations (based on generics). You are only overridng OnBefore, OnList or OnAfter operations.

And of course, you can append your own stuff.

UI Web

Web layer is the diamond, selling your application to the user. This fact is straighten by:

1) MasterPage containing areas (actions, navigation, language or role selectors), which can be adjusted to your needs - without any impact to other layers.

2) And what's more - web controls. There are no HTML HELPERS. The Catharsis framework introduced Smart WebControls, which gathers all the best you know:

• from ASP.NET WebControls (property setting, DataBinding) and
• from MVC world (every control has access to devoted IModel like IMasterModel)

Summary

All that together ends with one crucial approach: separation of concern.

Every layer is doing its own job, which is totaly independent on any upper or lower tier. This parts only publish interfaces and acts with published ones.

You can change one layer (Data to XML, View to WebServices etc.) without any impact to others.

Where to go next

The milestone for me was the article from Billy McCafferty – Dependency Injection for Loose Coupling.

Such type of architecture calls for reuse. (Did you already examine the ListWC web-control?)

Source Code 

http://www.codeplex.com/Catharsis

Enjoy Catharsis.

History   

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 2 of 2 (Total in Forum: 2) (Refresh) FirstPrevNext

Great agile practice!! himikel 0:31 26 Nov '08   I think this is a clear-layered design, explained in such a concise way. Is well prepared to practice agile development with it (see Agile Manifesto). But remember that to apply agile practices and to obtain a well-balanced result are in your hands. Congratulation Radim, you have completed the first step. (see Agile Architecture: Strategies for Scaling Agile Development) Please to meet you Mikel Ihidoi "himikel" Sign In·View Thread·PermaLink Re: Great agile practice!! Radim Köhler 0:40 26 Nov '08   Hi Mikel It is always nice to see, that there are guay, developers or architects, who are on the same wave ... Thanks for your note. Enjoy good architecture Radim Köhler Competition is as important as Cooperation Sign In·View Thread·PermaLink

Last Visit: 12:07 9 Feb '10     Last Update: 12:07 9 Feb '10 1