Expect everything to change...

Excellent intro article to "The Webkit Inspector" or "Chrome Developers Tools" as I know them....

http://jtaby.com/2012/04/23/modern-web-development-part-1.html

Overview

N-Tier architecture is an industry-proved software architecture model, suitable to support enterprise-level client/server applications by resolving issues like scalability, security, fault tolerance and etc. .NET has many tools and features, but .NET doesn’t have pre-defined ways to guard how to implement N-Tier architecture.

N-Tier Architecture Introduction.

Tier and Layer

Firstly we need to clarify the difference between two terms in N-Tier architecture: tier and layer. Tier usually means the physical deployment computer. Usually an individual running server is one tier.
By contrast, layer usually means logic software component group mainly by functionality; layer is used for software development purpose.
Each layer may run in an individual tier. However, multiple layers may also be able to run in one tier.
there's more...

Tier and Process

If a layer can run in an individual process, usually it will also be able to run in an individual computer (tier), hence it can be considered capable for an individual tier in N-Tier architecture. However, this isn’t always true, if there are two layers which are implemented to run in two individual processes but they communicate in a such way that their IPC (inter-process communication) is solely based on a non-distributed way, such as the local shared memory, then these two layers can run in two different processes only in the same computer, not in two different computers.

Layer and Process

A layer may run in an individual process; several layer may also run in an individual process; a layer may run in several processes too. If you read above section “Tier and Layer Relationship”, you can understand here easily.

3-Tier Architecture

The simplest of N-Tier architecture is 3-Tier which typically contains the following software component layers: presentation layer, application layer and data layer, which are depicted below.





A layer can access directly only the public components of its directly-below layer. For example, presentation layer can only access the public components in application layer, but not in data layer. Doing so can minimize the dependencies of one layer on other layers. This dependency minimization will bring benefits for layer development/maintenance, upgrading, scaling and etc. Doing so also makes the tier security enforcement possible. Finally, doing so can also avoid cyclic dependencies among software components.

In order to claim a complete 3-Tier architecture, all three layers should be able to run in separate computers.

These three layers are briefly described as below:
Presentation layer: a layer that users can access directly, such as desktop UI, web page and etc. Also called client.
Application layer: this layer encapsulates the business logic (such as business rules and data validation), domain concept, data access logic and etc. Also called middle layer.
Data layer: the external data source to store the application data, such as database server, CRM system, ERP system, mainframe or other legacy systems and etc. The one we meet often today is database server. For N-Tier architecture, we need to use the non-embedded database server, such as SQL server, Oracle, DB2, MySQL or PostgreSQL. The non-embedded database server can be run in an individual computer. Whereas, the embedded type databases, such as Microsoft access, dbase and etc, cannot run in an individual computer, and then cannot be used as the data layer of the 3-Tier architecture.

1, 2, 3 or More Tier Architecture

1-Tier: all above layers can only run in one computer. In order to achieve 1-Tier, we need to use the embedded database system, which cannot run in an individual process. Otherwise, there will be at least 2-Tier because non-embedded databases usually can run in an individual computer (tier).
2-Tier: either presentation layer and application layer can only run in one computer, or application layer and data layer can only run in one computer. The whole application cannot run in more than 2 computers.
3-Tier: the simplest case of N-Tier architecture; all above three layers are able to run in three separate computers. Practically, these three layers can also be deployed in one computer (3-Tier architecture, but deployed as 1-Tier).
N-Tier: 3 or more tiers architecture. Diagram 2 below depicts a typical N-Tier architecture. Some layers in 3-Tier can be broken further into more layers. These broken layers may be able to run in more tiers. For example, application layer can be broken into business layer, persistence layer or more. Presentation layer can be broken into client layer and client presenter layer. In diagram 2, in order to claim a complete N-Tier architecture, client presenter layer, business layer and data layer should be able to run in three separate computers (tiers). Practically, all these layers can also be deployed in one compute (tier).





Below are brief summaries on all layers in Diagram 2:
Client layer: this layer is involved with users directly. There may be several different types of clients coexisting, such as WPF, Window form, HTML web page and etc.
Client presenter layer: contains the presentation logic needed by clients, such as ASP .NET MVC in IIS web server. Also it adapts different clients to the business layer.
Business layer: handles and encapsulates all of business domains and logics; also called domain layer.
Persistence layer: handles the read/write of the business data to the data layer, also called data access layer (DAL).
Data layer: the external data source, such as a database.

Advantages and Disadvantages of Different Tier Architectures

1 or 2-Tier

Advantages: simple and fast for a lower number of users due to fewer processes and fewer tiers; low cost for hardware, network, maintenance and deployment due to less hardware and network bandwidth needed.
Disadvantages: will have issues when the number of users gets big; as limitation to solve issues like security, scalability, fault tolerance and etc because it can be deployed in only 1 or 2 computes.

N-Tier Architecture

Advantages: the following are general advantages:


loads of dis/advantages and tips can be found on the excellent article this is based on:
http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips

Robert C Martin introduced the acronym SOLID in the early 2000s to communicate five high level principles for object oriented programming. The five principles are:

Single Responsibility – an object should have only one responsibility.

Objects created in this fashion are considered more durable over the long term because they have only one reason to change. Using the single responsibility principle will cause you to have many more classes.
However, the more granular your classes become, the easier it will be to maintain and modify those classes without impacting a large portion of your code.
http://codebetter.com/karlseguin/2008/12/05/get-solid-single-responsibility-principle/

Open/Closed – an object is open for extension, but closed for modification.

This principle is implemented by utilizing the other SOLID principles in conjunction with object oriented development patterns. How do you make modifications, sometimes major modifications, without breaking your existing code? Applying the open/closed principle you would not modify the existing code; rather, through implementing software development patterns, you would add new functionality, taking advantage of the existing software, without changing the way it works internally.
That is the reason that SOLID is an acronym. Each of the principles work hand in hand and cannot stand alone. For example, the Single Responsibility pattern we reviewed yesterday provides a framework for Open/Closed. If each object has a single responsibility, it is a lot easier to lock them down (Close) while still adding new functionality at a later time (open).
If you would like to see an example of code techniques implementing Open/Closed, I found a great article in MSDN magazine by Jeremy Miller, http://msdn.microsoft.com/en-us/magazine/cc546578.aspx, from 2008 demonstrating how the SOLID principles may be implemented through different object oriented patterns.

Liskov Substitution – An object should be replaceable with instances of a subtype without altering the correctness of a program.

Liskov postures that your specific class implementations should utilize an abstract implementation of external objects. In so doing, you can change the functionality of that class by substituting a different implementation of the abstract external object with another, and the containing class need not be modified in any way. In essence, this is one technique for fulfilling the Open/Closed principle.
an object called BusinessProcess. BusinessProcess requires interaction with a data source. Rather than instantiating a specific data source the BusinessProcess class utilizes an IDataSource interface. By using an interface the BusinessProcess object works with any implementation of the IDataSource interface.
The IDataSource interface can be implemented by an XML data store. Later it may be implemented with a relational database data store without modifying the BusinessProcess class in any manner.
In this fashion, Single Responsibility, Open/Closed and Liskov Substitution work together resulting in code that may be easily extended with the least impact to existing code. Utilizing other software development patterns, new implementations of IDataSource may be created, instantiated, and inserted into the program for execution by adding only new code, and modifying configuration data for implementation.

Interface Segregation – segregated interfaces are better than on single general purpose interface.

Unlike the other principles we have covered up to this point, Single Responsibility, Open/Closed, and Liskov Substitution, the Interface Segregation Principle is less transferable to languages that are not object oriented.
If I were to summarize the principle into one sentence it would be, “it is better to have more tightly defined interfaces rather than fewer comprehensive interfaces.”.
A rule of thumb might be, if you can foresee a realistic potential for the need to separate an interface into smaller interfaces because the interface contains features that do not apply to all implementations, then it makes sense to break it out.
This is where refactoring comes into play. Perhaps your interface was too general when you started out. That doesn’t mean you can’t break the interface out into smaller more granular interfaces at a later date. It just takes more work; especially if you don’t have automated unit tests to prove your refactoring work hasn’t broken your business requirements.

Dependency Inversion = Base your code on abstractions such rather than concrete implementations.

If your class dependencies are based on abstractions (Interface or abstract class) then the classes implementing the abstractions may be replaced without impacting any and every consumer.
Dependency Injection is a good implementation of the Dependency Inversion Principle. Using Dependency Injection, a consumer passes a desired kind of implementation to a class capable of resolving the correct implementation required, returning the correct object. container i guess.
One of my favorite examples is having a web app that can save data to a web service, an XML File, or a relational database. The user says, Save to XML. The web application knows nothing about how to save XML; but it knows how to call a persistence controller that returns a class that will save the data as an XML file. The Class supporting XML is based on an interface shared by the web application. The Web site, in this instance is injecting through a controller, the information necessary to implement the correct type of Class to persist the data to XML.
Dependency Injection is one technique of implementing Dependency Inversion. They are not equivalent concepts.


my thanks to: http://www.sswug.org/nlarchive.aspx
first email newsletter received on 30/07/2012