An n-tier application architecture is one which has at least three separate logical layers. Applications based on an n-tier architecture can be scaled easily and can handle more server load. Also, what each layer does internally is completely abstracted to other layers and this makes it possible to change or update one layer without modifying other layers. Hence, feature changes can be done without actually re-deploying the entire application.
Additionally, Communifire heavily uses the Provider & Factory Design Patterns throughout the application to support a plug-n-play based architecture, allowing customers to add customizations without modifying the core source code, essentially building up on Communifire.
Communifire application has an n-tier architecture, so the source code is divided into these tiers:
Point worth noting is that Communifire BL and Communifire DAL are loosely coupled layers. The BL will never call DAL directly. It will however, call Communifire.Providers.
This project acts as the business logic layer and contains all business logic for Communifire. The UI will NOT contain any business logic. All repositories such as ArticleRepository.cs, BlogRepository.cs exist in the BL. These repositories in turn contain all behaviours such as add, delete, update, fetch etc. It is the middle-man between the UI and DAL.
Communifire.Common behaves as a common project for other tiers. The DLL of this project can be accessed by other projects.
Business Classes, DTOs, Enums and various helper/utility classes are included in this projects, existing in the application.
Just as the name suggests, the data access layer or DAL is the layer that interacts directly with the database and all database specific code is written inside this layer.
As mentioned above, Communifire DAL and BL are loosely coupled layers and to make this happen, a Provider Model has been implemented.
Per the provider Model, BL will call the provider layer instead of DAL and the provider layer will check the config files before the interaction between BL and DAL (through providers) take place. Based on the config settings, the provider will decide, which DAL needs to be called. The provider model enables the client to implement a completely new DAL without breaking the code.
Minor changes will be made to Config files, however.
Communifire has an in-built Caching framework based on the Communifre Provider model. This framework supports adding multiple caching providers, like memcached, scaleout etc by modifying the config file settings. By default, CF comes with a default caching option (CFCacheProvider) which uses ASP.NET caching. CFCacheProvider is the recommended setting if you are using Communifire on a single server and not on a web farm or multiple servers.
For hosting on a web farm with multiple servers, you can either use MemcacheProvider (which comes with Communifire) or create your own custom caching provider.
Communifire has an in-built email framework based on the provider model. This framework is contained in the project Communifire.Emails and it supports adding multiple emailing providers like cf article email provider, cf blog email provider to the application and contains all classes for email sending. All code related to email sending is written in this project (none in UI or BL). Since, this is a loosely coupled layer, it enables the application user to change the way emails are being sent within the application without breaking the code. The client may make their own concrete class in order to enable email sending.
Communifire supports event-driven model which makes it easy to "hook" onto certain events and plug in your own custom code. You can link each event to as many modules as required. The instance an event is fired, the module will recieve the information and initiate the necessary module based action. for example: the moment an article is published, the news feed should display new activitiy. In this case, when an article is created, an event is fired by BL, via, Common and is captured by module layer: dyve article news feed manager.the publishing of the article is an event and news feed the module.
Communifire.Modules layer, is meant to contain all such modules in the entire application.
This is the web project (WAP).
Presentation Tier will call the Business Tier and the Business Tier will call the Data Tier.
It contains all user forms and user controls as well the Codebehind of those Web Forms and User Controls. All config files (which we shall discuss in a short while), script files and images are present in this project.
Process (screen shots below)
To open the solution just click the Communifire-Solution (.sln type file).
The solution will open in Visual Studio.
To run the solution make the Communifire.Web project as the start project.
To run the project either press F5 or click the start debugging icon.
After running the project the default browser set for Visual studio will open and you will see the application running on it.
Now the above part of this Wiki was for runnig the project in the production environment, if you want to publish it on the live server you need to have the published files.
Click on the Communifire.Web project and then from the Build menu select Publish Communifire.Web
A new modal window will open , After specifying the path where you want to publish your files click the publish button.
And thats it the published files are ready to be serve for the live server.
is requesting access to a wiki that you have locked: https://my.axerosolutions.com/spaces/5/communifire-documentation/wiki/view/319/architecture