Using patterns to build a robust 3-tier architecture

Many .NET applications do not benefit from a robust 3-tier architecture. Instead they have all their code (UI, business logic, and data access) in one place: the code behind.

The initial development cycle may be shorter, but in the long run you'll find that these applications do not evolve well with changing business needs. They are hard to maintain, nearly impossible to change, difficult to integrate (expose as a Web Services for example), and they do not scale very well (for when your website becomes an instant success!).

Here are some details on the 3-tier pattern architecture in Patterns in Action:

3-tier application model:

 In a 3-tier model each tier corresponds directly to one of the three elements needed in an architecture: interaction, manipulation, and storage. The three tiers or layers are:

Presentation layer — handles external interaction with the user

Business layer — manipulates the information required by the user

Database layer — stores the data handled by the system

Now, 3-tier architectures are widely accepted as a high-level best practice approach. However, as a .NET developer additional questions remain. For example, how is each tier built and and how do the tiers communicate with each other?


Below is a cross-section that shows some of the technologies used and the communication between the layers. The right-hand-side shows some of the key design patterns used in the reference application. Clearly, patterns play an integral role throughout the entire 3-tier architecture.
 

3-tier cross-section: 

Here are some details on the tiers and their relationships:

The PL: The concern of the Presentation Layer (PL) is to present information in a consistent and easy-to-understand manner to the end-user. Patterns in Action includes fully functional implementations of three UI platforms: ASP.NET, Windows Forms and WPF (Windows Presentation Foundation).

From PL to WCF: Each of the 3 UI platforms consume the exact same services hosted under WCF. This service-oriented model is an implementation of the Application Facade Design Pattern. Applications designed this way have the ability to expose their Services (Web or otherwise) with no extra work (other than configuring the WCF host). WCF is truly a powerful new platform!

From WCF to BL: The WCF Service Layer receives messages from the PL. It interprets the message, unpacks the Data Transfer Objects, and orchestrates and coordinates the interaction between Business Objects and Data Access Objects. The Services Layer is also the place where authorization, authentication, data validation, and database transactions are implemented.

The BL: In the Business Layer (BL) you'll find Business objects, such as, Product, Customer, and Order. Business Objects encapsulate business logic in the form of business rules. Business Objects themselves have no knowledge about databases or data persistence, which is handled by the DL.

From BL to DL: In fact, Business Objects do not directly interact with the Data Layer (DL).You don't ask a Product business object to save itself and there are no Save or Load methods on the Business Objects themselves. Instead, persistence is handled by dedicated Data Access Objects (another Enterprise Pattern) that extract data from the Business Objects and subsequently store it in the database.

The DL: The Data Layer (DL) handles the persistence of Business Objects. Patterns in Action offers two different technologies: ADO.NET and LINQ-to-SQL. In web.config you indicate which one to use. ADO.NET implements a 'data provider factory' which uses an abstract factory pattern and returns database specific singleton factories. This example shows that design patterns frequently work together with other patterns. When using LINQ-to-SQL you will see that LINQ generated Entities are mapped to Business Objects.

Following this review, we'd like you to walk away with the following important observation:

Have you noticed that there are no direct interactions between the PL and the BL or DL? In other words, the UI only interacts with the application via the Service Layer. This is by design. The reason is that security, data validation, and transactions are managed at the Service Layer. The UI is never allowed to bypass these important functions. Therefore, all communication with the application must go through this single point-of-entry (Application Facade) which is hosted under WCF.
 

Building a 3-tier application structure

Once you've decided to build your .NET application following a modern, pattern-based, 3-tier architecture, you may be asking yourself: How do I organize and structure my Visual Studio .NET Solution and Projects? Patterns in Action will demonstrate exactly how this is done - again, with great documentation and 100% pure source code.

Below are 3 annotated screenshots that show the Solution Explorer of this reference application.

The first screenshot shows the layers in the application. They have been numbered so that they display in a logical top-to-bottom order.
 

Physical Layers in 'Patterns in Action': 

 The next screenshot shows all 21 projects. Notice the 4 different UI platforms in the Presentation Layer (ASP.NET MVC, ASP.NET Web Forms, WinForms, and WPF). Again, each of these UI platforms consume the exact same services in WCF, which, in turn, rely on the same Service-, Business-, and Data-Layers (discussed below).

Projects in 'Patterns in Action':      

Finally, the third screenshot shows the complete set of re-usable classes, types, and design patterns that you will receive with your Patterns in Action solution:

Classes and other Types in 'Patterns in Action':   



reference: dofactory

Sarbanes-Oxley Act (SOX)

The Sarbanes-Oxley Act of 2002 (often shortened to SOX) is legislation enacted in response to the high-profile Enron and WorldCom financial scandals to protect shareholders and the general public from accounting errors and fraudulent practices in the enterprise. The act is administered by the Securities and Exchange Commission (SEC), which sets deadlines for compliance and publishes rules on requirements. Sarbanes-Oxley is not a set of business practices and does not specify how a business should store records; rather, it defines which records are to be stored and for how long.

The legislation not only affects the financial side of corporations, it also affects the IT departments whose job it is to store a corporation's electronic records. The Sarbanes-Oxley Act states that all business records, including electronic records and electronic messages, must be saved for "not less than five years." The consequences for non-compliance are fines, imprisonment, or both. IT departments are increasingly faced with the challenge of creating and maintaining a corporate records archive in a cost-effective

fashion that satisfies the requirements put forth by the legislation.

FAQ: What is the impact of Sarbanes-Oxley on IT operations?

The following sections of Sarbanes-Oxley contain the three rules that affect the management of electronic records. The first rule deals with destruction, alteration, or falsification of records.

Sec. 802(a) "Whoever knowingly alters, destroys, mutilates, conceals, covers up, falsifies, or makes a false entry in any record, document, or tangible object with the intent to impede, obstruct, or influence the investigation or proper administration of any matter within the jurisdiction of any department or agency of the United States or any case filed under title 11, or in relation to or contemplation of any such matter or case, shall be fined under this title, imprisoned not more than 20 years, or both."

The second rule defines the retention period for records storage. Best practices indicate that corporations securely store all business records using the same guidelines set for public accountants.

Sec. 802(a)(1) "Any accountant who conducts an audit of an issuer of securities to which section 10A(a) of the Securities Exchange Act of 1934 (15 U.S.C 78j-1(a)) applies, shall maintain all audit or review workpapers for a period of 5 years from the end of the fiscal period in which the audit or review was concluded."

This third rule refers to the type of business records that need to be stored, including all business records and communications, including electronic communications.

Sec. 802(a)(2) "The Securities and Exchange Commission shall promulgate, within 180 days, such rules and regulations, as are reasonably necessary, relating to the retention of relevant records such as workpapers, documents that form the basis of an audit or review, memoranda, correspondence, communications, other documents, and records (including electronic records) which are created, sent, or received in connection with an audit or review and contain conclusions, opinions, analyses, or financial data relating to such an audit or review."

 Clause 49 is an Indian adaptation of SOX; requiring CEO- CFO to assume responsibility for Internal controls over financial reporting at their organizations. CEO/CFO is a subset Clause 49 of the listing agreement with Securities Exchange Board of India (SEBI).

Agile and Waterfall differences

One of the most important differences between the agile and waterfall approaches is that waterfall features



distinct phases with checkpoints and deliverables at each phase, while agile methods have iterations rather


than phases. The output of each iteration is working code that can be used to evaluate and respond to


changing and evolving user requirements.
Waterfall assumes that it is possible to have perfect understanding of the requirements from the start. But



in software development, stakeholders often don’t know what they want and can’t articulate their requirements.


With waterfall, development rarely delivers what the customer wants even if it is what the customer asked for.


Agile methodologies embrace iterations. Small teams work together with stakeholders to define quick prototypes,


proof of concepts, or other visual means to describe the problem to be solved. The team defines the


requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users


verify the results. Verification occurs much earlier in the development process than it would

with waterfall, allowing stakeholders to fine-tune requirements while they’re still relatively easy to change. 

 
refer: http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf

GoF patterns summary for reference

Creational
Abstract Factory	Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
Builder	Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Factory Method	Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Prototype	Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Singleton	Ensure a class only has one instance, and provide a global point of access to it.
Structural
Adapter	Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
Bridge	Decouple an abstraction from its implementation so that the two can vary independently.
Composite	Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Decorator	Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Façade	Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Flyweight	Use sharing to support large numbers of fine-grained objects efficiently.
Proxy	Provide a surrogate or placeholder for another object to control access to it.
Behavioural
Chain Of Responsibility	Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
Command	Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
Interpreter	Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
Iterator	Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
Mediator	Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
Memento	Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
Observer	Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
State	Allow an object to alter its behaviour when it’s internal state changes. The object will appear to change its class.
Strategy	Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
Template Method	Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
Visitor	Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

 

Design Patterns vs Design Principles (SOLID)

I was reading the other day a discussion on Design Patterns versus Design Principles called SOLID.

For those who are not aware of this, SOLID is an acronym for the first 5 principles of object-oriented design:


SRP The Single Responsibility Principle: -- a class should have one, and only one, reason to change.
OCP The Open Closed Principle: -- you should be able to extend a class's behavior, without modifying it.
LSP The Liskov Substitution Principle: -- derived classes must be substitutable for their base classes.
ISP The Interface Segregation Principle: -- make fine grained interfaces that are client specific.
DIP The Dependency Inversion Principle -- depend on abstractions not on concrete implementations.
You'll find a fair amount of information on the web on these principles.

It seems to me that you need a good grasp of the SOLID principles before you're ready to tackle Design Patterns (in more of an Architect role).

http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html

UML 2.0 link

Diagram	Description	Learning Priority
Activity Diagram	Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. See UML Activity diagram guidelines.	High
Class Diagram	Shows a collection of static model elements such as classes and types, their contents, and their relationships. See UML Class diagram guidelines.	High
Communication Diagram	Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. See UML Collaboration diagram guidelines.	Low
Component Diagram	Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. See UML Component diagram guidelines.	Medium
Composite Structure Diagram	Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.	Low
Deployment Diagram	Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. See UML Deployment diagram guidelines.	Medium
Interaction Overview Diagram	A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram.	Low
Object Diagram	Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram.	Low
Package Diagram	Shows how model elements are organized into packages as well as the dependencies between packages. See Package diagram guidelines.	Low
Sequence Diagram	Models the sequential logic, in effect the time ordering of messages between classifiers. See UML Sequence diagram guidelines.	High
State Machine Diagram	Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. See UML State chart diagram guidelines.	Medium
Timing Diagram	Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events.	Low
Use Case Diagram	Shows use cases, actors, and their interrelationships. See UML Use case diagram guidelines.	Medium

http://www.agilemodeling.com/essays/umlDiagrams.htm

MVC or MVP Pattern – Whats the difference?

Over the years I have mentored many developers on using design patterns and best practices. One question that keeps coming up over and over again is: What are the differences between the Model View Controller (MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer is more complex than what you would suspect. Part of reasons I think many developers shy away from using either pattern is the confusion over the differences.

Before we dig into the differences let’s examine how the patterns work and the key benefits to using either one. Both (MVC & MVP) patterns have been use for several years and address a key OO principal namely separation of concerns between the UI and the business layers. There are a number of frameworks is use today that based on these patterns including: JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory, and the recently announced ASP.Net MVC framework.

Model View Controller (MVC) Pattern

The MVC pattern is a UI presentation pattern that focuses on separating the UI (View) from its business layer (Model). The pattern separates responsibilities across three components: the view is responsible for rending UI elements, the controller is responsible for responding to UI actions, and the model is responsible for business behaviors and state management. In most implementation all three components can directly interact with each other and in some implementations the controller is responsible for determining which view to display (Front Controller Pattern),

Model View Presenter (MVP) Pattern

 

The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier.

Key Benefits

Before using any pattern a developers needs to consider the pros and cons of using it. There are a number of key benefits to using either the MVC or MVP pattern (See list below). But, there also a few draw backs to consider. The biggest drawbacks are additional complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I’m my experience a have seen a few solutions eliminate a large amount of complexity but being re-factored to use either pattern.

 

·         Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other.

·         Clear separation of concerns/responsibility

o    UI (Form or Page) – Responsible for rending UI elements

o    Presenter/controller – Responsible for reacting to UI events and interacts with the model

o    Model – Responsible for business behaviors and state management

·         Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.

·         Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.

·         Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)

·         Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.

Key Differences

So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model).  The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers.

 

Here are the key differences between the patterns:

 

·         MVP Pattern

o    View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.

o    Easier to unit test because interaction with the view is through an interface

o    Usually view to presenter map one to one. Complex views may have multi presenters.

 

·         MVC Pattern

o    Controller are based on behaviors and can be shared across views

o    Can be responsible for determining which view to display (Front Controller Pattern)

 

Hopefully you found this post interesting and it helped clarify the differences between the MVC and MVP pattern. If not, do not be discouraged patterns are powerful tools that can be hard to use sometimes. One thing to remember is that a pattern is a blue print and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.

Software Design

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.

Design concepts
The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are:
1.Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.
2.Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a stepwise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts.
3.Modularity - Software architecture is divided into components called modules.
4.Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. A software architecture is the development work product that gives the highest return on investment with respect to quality, schedule and cost.
5.Control Hierarchy - A program structure that represent the organization of a program components and implies a hierarchy of control.
6.Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure.
7.Data Structure - It is a representation of the logical relationship among individual elements of data.
8.Software Procedure - It focuses on the processing of each modules individually
9.Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information.

Design considerations
There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects are:
Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself.
Extensibility - New capabilities can be added to the software without major changes to the underlying architecture.
Fault-tolerance - The software is resistant to and able to recover from component failure.
Maintainability - The software can be restored to a specified condition within a specified period of time. For example, antivirus software may include the ability to periodically receive virus definition updates in order to maintain the software's effectiveness.
Modularity - the resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project.
Packaging - Printed material such as the box and manuals should match the style designated for the target market and should enhance usability. All compatibility information should be visible on the outside of the package. All components required for use should be included in the package or specified as a requirement on the outside of the package.
Reliability - The software is able to perform a required function under stated conditions for a specified period of time.
Reusability - the modular components designed should capture the essence of the functionality expected out of them and no more or less. This single-minded purpose renders the components reusable wherever there are similar needs in other designs.
Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions.
Security - The software is able to withstand hostile acts and influences.
Usability - The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users. In many cases, online help should be included and also carefully designed.

Modeling language
A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. A modeling language can be graphical or textual. Examples of graphical modelling languages for software design are:
Business Process Modeling Notation (BPMN) is an example of a Process Modeling language.
EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data modeling language.
Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across a number of layers.
Flowchart is a schematic representation of an algorithm or a stepwise process,
Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems.
IDEF is a family of modeling languages, the most notable of which include IDEF0 for functional modeling, IDEF1X for information modeling, and IDEF5 for modeling ontologies.
Jackson Structured Programming (JSP) is a method for structured programming based on correspondences between data stream structure and program structure
LePUS3 is an object-oriented visual Design Description Language and a formal specification language that is suitable primarily for modelling large object-oriented (Java, C++, C#) programs and design patterns.
Unified Modeling Language (UML) is a general modeling language to describe software both structurally and behaviorally. It has a graphical notation and allow for extension with a Profile (UML).
Alloy (specification language) is a general purpose specification language for expressing complex structural constraints and behavior in a software system. It provides a concise language based on first-order relational logic.

Systems Modeling Language (SysML) is a new general-purpose modeling language for systems engineering.

Design patterns
A software designer or architect may identify a design problem which has been solved by others before. A template or pattern describing a solution to a common problem is known as a design pattern. The reuse of such patterns can speed up the software development process, having been tested and proved in the past.

Usage
Software design documentation may be reviewed or presented to allow constraints, specifications and even requirements to be adjusted prior to programming. Redesign may occur after review of a programmed simulation or prototype. It is possible to design software in the process of programming, without a plan or requirement analysis, but for more complex projects this would not be considered a professional approach. A separate design prior to programming allows for multidisciplinary designers and Subject Matter Experts (SMEs) to collaborate with highly-skilled programmers for software that is both useful and technically sound. preparing Functional Design documents, Technical design documents, Technical and System Architecture documents Technical requirements and Specification documents.

Stages and Phases of Design
Deriving a solution which satisfies software requirements. software design stages to be followed problem understanding identify one or more problem,describe solutions abstraction,repeat process for each identifier abstraction.
when design stages complete,phases design will take over which include architectural design,abstract specification,interface design,component design,data structure design and algorithm design.The design process may be modeled as a directed graph made up of entities with attributes which participate in relationship.Design takes place in overlapping stages,it is artificial to separate it into distinct phases but some separation is usually necessary.