Technical on Satellite Site

Design Principles - SOLID

2010-12-03T05:17:00.003-08:00

What are Software Design Principles?

Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices".

According to Robert Martin there are 4 important characteristics of a bad design that should be avoided. They are not orthogonal, but are related to each other in ways that will become obvious. they are:

rigidity, fragility, immobility, and viscosity.

These four symptoms are the tell-tale signs of poor architecture. Any application that show signs of them, is suffering from a design that is rotting from the inside out.


Rigidity	It is hard to change because every change affects too many other parts of the system.
Fragility	When you make a change, unexpected parts of the system break.
Immobility	Inability to reuse software from parts of the same project or from other projects. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. i.e. It is hard to reuse in another application because it cannot be separated from the current application.
Viscosity	Viscosity comes in two forms. High Viscosity is a bad design. · Viscosity of the design, & · Viscosity of the environment. Avoid hacks to solve a problem. When the hacks are easy to employ than the design preserving methods, the Viscosity Of The Design/Environment is high.

Single Responsibility Principle – SRP:

Principle - A class should have only one reason to change.

· In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes.

· Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it.

· When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

For example, instead of creating a class that has data access code for several different items you should instead separate the data access for each items into a seperate single class.

Single Responsibility Principle was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979.

Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

Open Close Principle - OCP

Principle - Software entities like classes, modules and functions should be open for extension but closed for modifications.

· OPC is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don't have to change the class, rather extend it.

· The same principle can be applied for modules, packages, libraries.

· If you have a library containing a set of classes there are many reasons for which you'll prefer to extend it. This extension should happen without changing the code that was already written.

For example, you should be able to add a new behavior to a class without affecting the rest of the code. Instead of adding a new case to a switch statement, you should consider re-factoring the code to use separate classes for each case.

When referring to the classes, OCP can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them. Some particular cases of this are Template Pattern & Strategy Pattern.

Liskov's Substitution Principle - LSP

Principle - Derived types must be completely substitutable for their base types.

That is, a user of a base class should continue to function properly, if a derivative of that base class is passed to it.

· This principle is just an extension of the OCP in terms of behavior, - Meaning that we must make sure that new derived classes are extending the base classes without changing their behavior. The new derived classes should be able to replace the base classes without any change in the code.

For example: A typical example that violates LSP is a Square (Derived) class that derives from a Rectangle(Base) class. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently.

Liskov's Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications.

Interface Segregation Principle - ISP

Principle - Clients should not be forced to depend upon interfaces that they don't use.

· This principle teaches us to take care how we write our interfaces.

· When we write our interfaces we should take care to add only methods that should be there.

· If we add methods that should not be there the classes implementing the interface will have to implement those methods as well.

For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

Another example - By having IEnumerable and IDisposable interfaces separate, it's possible for client code to seperately care about dealing with enumerating a collection or disposing of it. Thus not clutter up either operation by mixing two totally different kinds of behaviors.

As a conclusion Interfaces containing methods that are not specific to it are called Polluted or Fat Interfaces. We should avoid them.

Dependency Inversion Principle - DIP

Principle - High-level modules should not depend on low-level modules. Both should depend on abstractions and not concretions.

Abstractions should not depend on details. Details should depend on abstractions.

· Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

· Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework, …) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter, …) and an external module controlling the dependencies will inject the reference to the second one.

· By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module.

Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.

Hope this helps.

Reference :

Design Principles

Design Principles – By Example

Thanks & Regards,

Arun Manglick

Design Principles - SOLID - Proof Of Concept

2010-12-03T05:17:00.001-08:00

Open Close Principle - OCP

Principle - Software entities like classes, modules and functions should be open for extension but closed for modifications

Consider below code. The LogOn function must be changed every time a new kind of modem is added to the software.

Worse, since each different type of modem depends upon the Modem::Type enumeration, each modem must be recompiled every time a new kind of modem is added.

struct Modem

{

enum Type {hayes, courrier, ernie) type;

};

void LogOn(Modem m,string pno)

{

if (m.type == Modem::hayes)

DialHayes((Hayes&)m, pno);

else if (m.type == Modem::courrier)

DialCourrier((Courrier&)m, pno);

else if (m.type == Modem::ernie)

DialErnie((Ernie&)m, pno)

// ...you get the idea

}

Of course this is not the worst attribute of this kind of design.

Programs that are designed this way tend to be littered with similar if/else or switch statement.

Every time anything needs to be done to the modem, a switch statement if/else chain will need to add/select the proper functions to use.

When new modems are added, or modem policy changes, the code must be scanned for all these selection statements, and each must be appropriately modified.

Thus here - Logon, is modified to be extended – Breaking OCP.

OCP Solution :

class LogOn

{

public static void LogOn(Modem m)

{

m.Dial();

}

class MainApp

{

static void Main()

{

LogOn.LogOn(new HayesModem());

LogOn.LogOn(new CourierModem ());

LogOn.LogOn(new ErnieModem ());

}

Here the LogOn function depends only upon the Modem interface.

Additional modems will not cause the LogOn function to change.

Thus, we have created a module that can be extended, with new modems, without requiring modification.

Interface Segregation Principle - ISP

Principle - Clients should not be forced to depend upon interfaces that they don't use.

Below shows a class with many clients, and one large interface to serve them all.

Note that whenever a change is made to one of the methods that ClientA calls, ClientB and ClientC may be affected.

It may be necessary to recompile and redeploy them. This is unfortunate.


class Service : IServiceA,IServiceB,IServiceC { public string Swim() { return "Animal Swimming"; } public string Fly() { return "Animal Flying"; } public string Run() { return "Animal Running"; } }
class ClientA { Service service; public ClientA(Service service) { this. service = service; } public string Execute() { return running.Swim(); return running.Fly (); return running.Run(); } }	class ClientB { Service service; public ClientA(Service service) { this. service = service; } public string Execute() { return running.Fly(); return running.Swim(); return running.Run(); } }	class ClientC { Service service; public ClientA(Service service) { this. service = service; } public string Execute() { return running.Run(); return running.Swim(); return running.Fly(); } }
Here you can see that: Even the ClientA, does not the need the Fly and Run services, it can access those. Thus if any change is made in Fly and Run, CleintA also need to be changed. Same applies for CleintB & C. This breaking the rule.

A better technique is shown below. The methods needed by each client are placed in special interfaces that are specific to that client.

Those interfaces are Multiply Inherited by the Service class, and implemented there.

Now, If the interface for ClientA needs to change, ClientB and ClientC will remain unaffected. They will not have to be recompiled or redeployed.


public interface IServiceA { string Swim(); }	public interface IServiceB { string Fly(); }		public interface IServiceC { string Run(); }
class Service : IServiceA,IServiceB,IServiceC { public string Swim() { return "Animal Swimming"; } public string Fly() { return "Animal Flying"; } public string Run() { return "Animal Running"; } }
class ClientA { IServiceA running; public ClientA(IServiceA running) { this.running = running; } public string Execute() { return running.Swim(); } }		class ClientB { IServiceB animal; public ClientB(IServiceB animal) { this.animal = animal; } public string Execute() { return animal.Fly(); } }		class ClientC { IServiceC animal; public ClientC(IServiceC animal) { this.animal = animal; } public string Execute() { return animal.Run(); } }
Here you can see that: The ClientA, has access to only the relevant Swim service. It cannot access the Fly and Run services. Thus if any change is made in Fly and Run, CleintA will not be affected. Same applies for CleintB & C. This serving the ISP rule.

Hope this helps.

Thanks & Regards,

Arun Manglick

Architecture - What is Scalability

2010-12-01T05:35:00.001-08:00

The very first question in any Architecture discussions/interviews – How to make your application Scalable.

Before answering, it's better to know what is 'Scalability'.

Few definitions:

ü In software engineering, scalability is a desirable property of a system, which indicates its ability to handle growing amounts of work in a graceful manner.

ü Indicates the capability of a system to increase total throughput under an increased load(more users) when resources (typically hardware) are added.

ü A term that refers to how well a hardware and software system can adapt to increased demands.

ü Refers to the ability of an application to increase total throughput to handle the growing needs of data flow.

ü It is the ability of a computer application or product (hardware or software) to continue to function well when it is changed in size or volume, in order to meet a user need.

Scalability is a design concern of Distributed Applications and not Stand-Alone Applications.

Distributed applications are a step beyond traditional client-server applications. Distributed applications are applications that are designed as n-tier applications.

Such distributed application architectures promote the Design Of Scalable Applications by sharing resources, such as business components and databases.

Scaling comes in two flavours - Scale Up (vertically) vs. Scale-out (horizontally).

Scale-Up: (Adding More Memory/Processors – To a Single Machine)

Scale up means to add resources to a single node in a system.

I.e. Scaling up includes adding more memory, adding more or faster processors, or simply migrating the application to a more powerful, But Single Machine.

Such vertical scaling of existing systems also enables them to use virtualization technology more effectively.

Defeciences:

Scaling up requires more expensive hardware, as single machine is upgraded. It's like using Smart/Expensive Server having Symmetric Multi-Processor (SMP) configurations.

Upgrading a hardware component in a single machine simply moves the processing capacity limit from one part of the machine to another part.

Adding more processors does not add performance in a linear fashion. Instead, the performance gain curve slowly tapers off as each additional processor is added.

For machines with symmetric multi-processor (SMP) configurations, each additional processor incurs system overhead. Consequently, a four-processor machine will not realize a 400 percent gain in capacity over the uniprocessor version. Once you have upgraded each hardware component to its maximum capacity, you will eventually reach the real limit of the machine's processing capacity.

Scaling up also presents other potential problems. Using a single machine to support an application creates a single point of failure, which greatly diminishes the fault tolerance of the system. While methods, such as multiple power supplies, may implement redundancy in a single-machine system, these options can be expensive.

Scale-Out: (Adding more Machines/Servers)

Scale Out means to add more nodes to a system, such as adding a new computer to a distributed software application.

Scaling out is less expensive, as it requires commodity PC hardware to distribute the processing load across more than one server.

Although scaling out is achieved using many machines, the collection essentially functions as a single machine.

By dedicating several machines to a common task, application fault tolerance is increased.

Developers and administrators use a variety of Load Balancing Techniques to scale out with the Windows platform.

Load balancing allows a site to scale out across a cluster of servers, making it easy to add capacity by adding more Replicated Servers.

It also provides Redundancy, giving the site failover capabilities so that it remains available to users even if one or more servers fail (or need to be taken down for maintenance).

Scaling out provides a method of scalability that is not hampered by hardware limitations. Each additional server provides a near linear increase in scalability.

The key to successfully scaling out an application is Location Transparency. If any of the application code depends on knowing what server is running the code, location transparency has not been achieved and scaling out will be difficult. This situation is called Location/Server Affinity.

Of course, from the administrator's perspective, scaling out also presents a greater management challenge due to the increased number of machines

Hope this helps.

Regards,

Arun Manglick

n-Tier Architecture

2010-12-01T05:06:00.001-08:00

Introduction

This document describes the details of four tier implementation of the new architecture.

The scope of this document is demonstrating the four tier implementation of the new architecture.

This document is primarily targeted for the developers and architects working on the Veriphy applications. It provides a useful perspective to other stakeholders such as managers, and the customer.

Overall Description

In this scenario, the solution is divided across four separate tiers, or physical machines.

· The client workstation represents first tier that uses a browser application to interact with the Web server.

· The Web server represents a second tier that contains the presentation layer, which is responsible for handling requests from the user and interacting with the business layer to implement the request.

· The application server represents the third tier with service, business, and data access layers.

· The fourth tier in this design is the database server.

Tiered Diagram

· Browser interaction with the Web Server uses standard HTTP GET and POST requests.

· The presentation layer uses a request-based / message-based protocol to interact with the service layer.

· The Service Layer uses a Facade call to interact with the business layer.

· Stand-alone ASP.NET Web application that supports basic CRUD operations.

· Presentation and Business logic are distributed across physical boundaries.

· DAL implementation will be implemented using LINQ.

· The application uses data from an existing database schema.

· Tables and views in the database define data structures used by the application

Another View

Detailed Tiered/Layered

The following is a summary of the patterns used by this scenario:

· User interface processing is handled by a Request-Response pattern.

· The user interface is composed of multiple controls, with some that can be bound to data elements.

· An Http-Get request / Proxy is used to communicate between the presentation layer and service layer

· The Data Transfer Object (DTO) pattern is used to package multiple data structures into one.

· The Service Layer provides translation between internal and external data structures.

· The Business Layer uses a façade pattern to support coarse-grained message-based operations.

· Transactions and Business Logic are managed by objects in the business layer.

· Business entities are defined using the Table Module pattern (LINQ).

· The Table or Row Data Gateway pattern is used to provide a data access interface.

· The Query Object pattern is used to support the generation of SQL queries.

Technical Details

Client Workstation

Target browser is Internet Explorer 6.x and higher

Browser will initiate the further flow.

Web Server


ASP.NET Page Control	ASP.NET Page controls are used to define each page of the web application. Standard ASP.NET page processing is used to handle control events.
Composite View	Page, server and user controls represent a Composite View.
Bound Data Control	Control that can be bound to a data structure, which is used to provide data displayed by the control.
Proxy	Provides a local interface used to interact with services on the application tier. Adding a service reference will generate classes used to interact with the service. From a coding perspective the proxy provides a local interface that hides details related to interaction with the service. Proxy is used when the presentation layer is required to communicate using WCF contracts.

Application Server – Service Layer


Service Interface	The service layer can be Class Library Project or could be defined using WCF service, data, message, and fault contracts. Operations exposed by the service are application scoped. For example, instead of providing multiple operations to return demographic information you would provide one operation that returns all data related to demographic information.
Data Transfer Object	Used to combine multiple data structures into a unified view that can be passed across physical and logical boundaries.
Entity Translator	Implement an object that transforms message data types to business types for requests and reverses the transformation for responses. Classes that provide operations to translate between business entities and WCF data contracts. Translate DTO to Business Entity Objects. Public LINQ.DataManager.Order TranslateOrderToOrderDTO();

Application Server – Business Layer

Façade Interface

The business layer implements a façade with coarse grained operations.

Implement a unified interface to a set of operations to reduce coupling between systems.

An Interface type is used to define the façade interface.

The Façade acts as a boundary that catches all unhandled exceptions that may occur when processing business operations.

public interface BusinessFacade

{

Data.Order GetData();

int SaveData(LINQ.Data.Order businessEntity);

bool DeleteData(int businessEntityID);

}

Business Process Objects

Business process objects are used to handle requests made to the business layer.

Business process objects allow you to Implement Business Rules And Provide Transaction support if required.

Business operations that need to be included in a transaction are combined in a single operation exposed by a business process object that implements the transaction script pattern.

public bool SaveData(LINQ.Data.Order businessEntity)

{

string sError = string.Empty;

bool success = false;

int orderId = -1;

try

{

BeginTransaction();

if (orderId == -1)

{

orderId = LINQ.DataManager.FindNextOrderID();

if (orderId == -1)

{

sError = "Failed to retrieve new Dealer ID. Rolling Back Transaction";

RollbackTransaction();

return success;

}

orderId = LINQ.DataManager.InsertOrder(businessEntity);

if( orderId == 0)

{

sError = "Failed to insert Dealer ID. Rolling Back Transaction";

RollbackTransaction();

return success;

}

CommitTransaction();

success = true;

}

catch (Exception ex)

{

RollbackTransaction();

}

return success;

}

Application Server – Data Access Layer

Table Module / Business Entities

Business entity that represents a table or view within a database and provides operations to interact with the table or view.

Business rules are not implemented within the business entities.

The business entities are just data containers. Business rules are handled by business processing components.

LINQ DataManager

Separate classes are used to define LINQ query objects.

It behaves like a gateway object - defined for each business entity in the design.

The gateway encapsulates all logic related to interacting with the associated DB table or view.

public int InsertOrder(LINQ.Data.Order order)

{

order.InstitutionID = _institutionId;

_dataContext.Orders.InsertOnSubmit(order);

_dataContext.SubmitChanges();

return order.OrderID;

}

Database Server

SQL Server DB

Tables and views are accessible to the Data Access Layer using LINQ ORM.

Reference: Link1, Link2

Hope this helps.

Thanks & Regards,

Arun Manglick

MVVM - Silverlight

2010-12-01T04:46:00.001-08:00

The Model View ViewModel (MVVM) is an architectural pattern used in software engineering that originated from Microsoft as a specialization of the Presentation Model design pattern introduced by Martin Fowler.

Why MVVM & Why not MVC or MVP:

In the MVC pattern, the Model is the data, the View is the user interface, and the Controller is the programmatic interface between the view, the model, and the user input.

This pattern, however, does not work well in declarative user interfaces like WPF or Silverlight. Reason, the XAML that these technologies uses can define some of the interface between the input and the view (Using Data Binding, Triggers, and states can be declared in XAML).

Model-View-Presenter (MVP) is another common pattern for layering applications.

In the MVP pattern, the presenter is responsible for setting and managing state for a view.

Like MVC, MVP does not quite fit the Silverlight model because the XAML might contain declarative Data Binding, Triggers, & State Management.

So where does that leave us?

Luckily for Silverlight , the WPF community has rallied behind a pattern called Model-View-ViewModel (MVVM).

This pattern is an adaptation of the MVC and MVP patterns in which:

· The ViewModel provides a data model and behavior to the View. This allows the View to declaratively bind to the ViewModel.

· The View becomes a mix of XAML and C#.

· The Model represents the data available to the application, and

· The ViewModel prepares the Model in order to bind it to the View.

Note: As the MVVM pattern is designed to support WPF and Silverlight, this pattern is only newly Available To The Public, as opposed to MVC or Model View Presenter (MVP).

MVVM:

Largely based on the MVC pattern, MVVM is targeted at modern UI development platforms (WPF & Silverlight).

MVVM pattern designed to gain two things.

· The advantages of separation of functional development provided by MVC

· And leveraging the advantages of XAML and the WPF, by binding data as close as possible to the Model while using the XAML. Thus minimizing the need for "code behind," especially in the View

· MVVM was designed to make use of specific functions in WPF & Silverlight, to better facilitate the separation of View layer development from the rest of the pattern.

· This is done by removing virtually all "code behind" from the View layer.

· Instead of requiring designers to write View code, they can use the native WPF markup language XAML and Create Bindings To The Viewmodel, which is written and maintained by application developers.

· This separation of roles allows designers to focus on UX needs rather than programming or business logic, allowing for the layers of an application to be developed in multiple work streams.

Elements of the MVVM pattern are described as below - Also similartiies with MVC.


Model	As in the classic MVC pattern, the model refers to either (a) An object model that represents the real state content (an object-oriented approach), or (b) The data access layer that represents that content (a data-centric approach).
View	As in the classic MVC pattern, the view refers to all elements displayed by the GUI such as buttons, windows, graphics, and other controls.
ViewModel	The ViewModel is a "Model of the View" that serves in data binding between the View and the Model. The View-Model of MVVM is responsible for exposing the data objects from the Model, in such a way that those objects are easily consumed in XAML. It is similar to the Controller (in the MVC pattern) that acts as a Data Binder that changes Model information into View information and passes commands from the View into the Model. The ViewModel exposes public properties, commands, and abstractions.
Controller	some references for MVVM also include a Controller layer or illustrate that the ViewModel is a specialized functional set in parallel with a Controller, while others do not. This difference is an ongoing area of discussion regarding the standardization of the MVVM pattern.

Criticism

There are currently three main areas of criticism regarding the MVVM pattern.

1. MVVM currently lacks standardization from Microsoft both in implementation and in toolsets

2. The overhead in implementing MVVM is "overkill" for simple UI operations. Also for larger applications, generalizing the View layer becomes more difficult.

3. Moreover, data binding, if not managed well, can result in considerable memory consumption in an application.

4. Exercise in creating large numbers of data bindings to the ViewModel results in duplicate code and maintenance problems.

Implementation:

	Model
	namespace Arun.Manglick.Silverlight.Model { public class Product : INotifyPropertyChanged { #region Private Variables private int productId; private string modelNumber; private string modelName; private double unitCost; private string description;

Design pattern - IOC & DI

2010-12-01T01:59:00.001-08:00

The Inversion of Control (IoC) pattern, is also known as Dependency Injection. Or In other words - IOC is implemented using DI. Or DI is the main method to implement IoC.

The target behind applying IOC and DI is to build Loosely Coupled Software Architecture.

IoC is not a new concept, however. It has been around for several years now. Using OO design principles and features such as Interface, Inheritance, and Polymorphism, the IoC pattern enables better software design that facilitates reuse, Loose Coupling, and easy testing of software components

The basic principle of IOC stands on the base of Bollywood principle – "Do not call us we will call you".

In other words it like aggregated class (here Address) saying to the container class (here Customer), do not create me I will create myself using some one else.

This article discusses IoC and demonstrates how to use this pattern in your software design with/without using any of the open source frameworks.

IoC Design Pattern

Lets understand this with an example.

Assume Class A has a relationship with Class B: it wants to use the services of Class B. The usual way to establish this relationship is to instantiate Class B inside Class A.

public class A

{

private B b;

public A()

{

b=new B();

}

Listing 1 - Class A Directly Refers Class B

public class A

{

private B b;

public A()

{

C c=new C();

b=new B(c);

}

Listing 2. Class A Directly Refers Class B and Class C

Though this approach works, it creates tight coupling between the classes. You can't easily change Class B without modifying Class A.

Here are the problems.

· This design assumes that - Class B is a concrete class that has a default constructor. Now If Class B is changed to have a non-default constructor, then Class A would also require a change.

· Also If Class B changed to have a non-default constructor, which takes Class C , then again the Class A would require a change.

· Now If Object "a" owns both Object "b" and Object "c". If Class B or Class C changes at all, then Class A needs to change as well.

In essence, a simple design of a simple class with implicit design assumptions becomes a maintenance nightmare in the future. Consider how difficult making changes would be if you had this scenario in a typical application with several classes.

Here comes the usage of 'IoC pattern Framework'.

Let's re-understand the above problem with realistic objects.

In the above code, the biggest issue is the tight coupling between classes. The same is found here in real-time example also.

IOC - Problem

Here, the Customer class depends on the Address object. So for any reason Address class changes it will lead to change and compiling of 'ClsCustomer' class also. I.e. You can't easily change Address class without modifying 'ClsCustomer' Class. For e.g.

· If Class Address is changed to have a non-default constructor, then Class Customer would also require a change.

· Now If Object "Customer" owns two Objects "Address" and "SocietyDetail". If these two Class changes at all, then Class Customer needs to change as well.

So let's put down problems with this approach:

The biggest problem is that Customer class controls the creation of Address object.
Address class is directly referenced in the Customer class which leads to tight coupling between address and customer objects.
Customer class is aware of the Address class type. So if we add new Address types like home address, office address it will lead to changes in the customer class also as customer class is exposed to the actual address implementation.

In essence - If for any reason the Address object is not able to create, the whole Customer class will fail in the constructor initialization itself – Very High/Tight Coupling.

Solution: IoC

The main problem roots from the customer class creating the address object. The solution is:

· Shift the task/control of object creation from the customer class to some other entity – Problem Solved.

· In other sentence if we are able to Invert this control to a third party we have found our solution. So the solution name is IOC (Inversion of control).

This is the opposite of using an API, where the developer's code makes the invocations to the API code. Hence, frameworks Invert the control: it is not the developer code that is in charge, instead the framework makes the calls based on some stimulus. I.e. Do not call us we will call you.

This solutiuon Achieves The Decoupling, and is refrerred to as - IOC (Inversion of control).

Here is the solution detail - Expose a method which allows us to set the address object. I.e. Let the address object creation be delegated to the IOC framework. IOC framework can be a class, client class or some kind of IOC container. So it will be two step procedure IOC framework creates the address object and passes this reference to the customer class.

Solution – Using DI

clsAddress objAddress = new clsAddress(..);

clsCustomer objCustomer = new clsCustomer;

objCustomr.setAddress(objAddress); // IOC Framework

The basic principle of IOC stands on the base of Hollywood principle - Do not call us we will call you (Translating for struggling actors)

In other words it like Address class saying to the Customer class, Do Not Create Me I Will Create Myself Using Some One Else.

There are two principles of IOC:

Main classes (Here like Customer) aggregating other classes (Here like Address) should not depend on the direct implementation of the aggregated classes (Here like Address). Both the classes should depend on abstraction. So the customer class should not depend directly on the address class. Both address and customer class should depend on an abstraction either using interface or abstract class.
Abstraction should not depend on details, details should depend on abstraction.

IoC Frameworks - Ways of implementing IoC

Ok, now we know the problem, let's try to understand the broader level solution. IOC is implemented using DI (Dependency injection).

We have discussed on a broader level about how to inject the dependency in the previous sections. In this section we will dive deeper in to other ways of implementing DI.

Several open source IoC frameworks like Windsor Container, Castle Windsor, Spring, PicoContainer, and HiveMind support the IoC pattern. While the general IoC principle is simple, each of these frameworks supports different implementations and offers different benefits. The IoC pattern can be implemented in four ways, as mentioned below.

The figure shows how IOC and DI are organized. So we can say IOC Is A Principle while DI Is A Way Of Implementing IOC. In DI we have four broader ways of implementing the same:

Constructor way
Exposing setter and getter (As in above examples)
Interface implementation
Service locator

Constructor Methodology

In this methodology we pass the object reference in the constructor itself. So when the client creates the object he passes the object in the constructor while the object is created.

Its main advantage is that only the creator knows about the referenced object.

This methodology is not suited for client who can only use default constructors. Then you need to go with a setter-based IoC.

IOC - Constructor Methodology

Figure: - Constructor based DI

Setter and Getter

This is the most commonly used DI methodology. The dependent objects are exposed through set/get methods of classes.

Setter-based IoC is good for objects that take optional parameters and objects that need to change their properties many times during their lifecycles.

The bad point is because the objects are publicly exposed it breaks the encapsulation rule of object oriented programming.

IOC – Setter & Getter

Figure: - Getter and Setter

Interface based DI

In this type of IoC, objects implement a specific interface from the IoC framework, which the IoC framework will use to properly inject the objects.

One of the main advantages of this type is that it doesn't need an external configuration file to configure the object references. Since you need to use the IoC framework's marker interface, the IoC framework knows how to glue the objects together.

The main disadvantage of this approach is that the marker interface ties your application to a specific IoC framework.

You can see in figure 'Interface based DI' we have implemented an interface 'IAddressDI' which has a 'setAddress' method which sets the address object.

This interface is then implemented in the customer class. External client / containers can then use the 'setAddress' method to inject the address object in the customer object.

IOC – Interface Based

Figure: - Interface based DI

Service Locator

The other way to inject dependency is by using service locator.

Your main class in need to aggregate the child object, will use the service locator to obtain instance of the address object.

The service locator class does not create instances of the address object, it provides a methodology to register and find the services which will help in creating objects.

IOC – Interface Based

Figure: - Service locator

Implementing the DI:

Here we'll see how we can implement DI using 'Programatically' and 'Open Source IoC Framework - Windsor container'

If you are starting a new project, you can choose any of the open source IoC frameworks based on your needs.

If you want to use the IoC pattern in your existing project then you need to write your own classes that support IoC. Though the open source frameworks offer off-the-shelf components and may provide many more features than your own implementation, you can still develop a set of classes that support the IoC pattern using either of the above approach.

Here for example – Constructor Approach.

IOC – Interface Based

interface IAddress

{

void AddAddress(string address);

}

public class Address : IAddress

{

public string address;

public void AddAddress(string address)

{

this.address = address;

}

public class ClsCustomer

{

IAddress address;

public ClsCustomer(IAddress address)

{

this.address = address;

}

public string GetAddress()

{

Type c = Type.GetType("Address", true, true);

if (typeof(IAddress).IsAssignableFrom(c))

{

return (objAddress as Address).MyAddress;

}

return string.Empty;

}

class Client

{

public void Run()

{

IAddress objAddress = new Address();

objAddress.AddAddress("India");

ClsCustomer customer = new ClsCustomer(objAddress);

string address = customer.GetAddress();

}

Ok, now lets see how this will work if we use the Windsor container.

Figure 'Windsor container' shows how it looks like. So

· Step 1 creates the Windsor container object.

· Step 2 and 3 register the types (Iaddress) and concrete objects(clsAddress, clsCustomer) in the container.

· Step 4 requests the container to create the customer object. In this step the container resolves and set the address object in the Constructor.

It's like - ClsCustomer customer = new ClsCustomer(objAddress);

· Step 5 releases the customer object.

IOC – Interface Based

Figure: - Windsor container

In actual implementation using the container we never use client code as above, rather we use config files.

You can see from figure 'Creating using config files' we have better flexibility to add more objects. In config file we need to define all the components in the components section.

The XmlInterpreter object helps to read the config file to register the objects in the container.

Using the Container.Resolve method we have finally created the customer object.

So the container plays the mediator role of understanding the Customer object and then injecting the Address object in the customer object through the constructor.

IOC – Interface Based

Figure: - Creating using config files

References: Link1, Link2

Hope this helps.

Thanks & Regards,

Arun Manglick

Date Validation

2010-11-29T22:46:00.001-08:00

Mostly found, data validation is slightly tricky. Checking against only Regurlar experession deos not serves the purpose. Here is the right apporach.

It involves two steps.

1. Check for proper format – Using Regex -

2. Chech for Date validity against Feburary Month (with and without Leap Year).

Here it is:


Step 1	string REGEXPR = @"^(0?[1-9]\|1[012])[- /.](0?[1-9]\|[12][0-9]\|3[01])[- /.](19\|20)\d\d$"; bool res = Regex.IsMatch(yourDate, REGEXPR);
Step2:	string date = "02/29/2009"; bool res = true; try { DateTime testDate = Convert.ToDateTime(date); } catch { res = false; } MessageBox.Show(res.ToString()); // False

These steps certifies the date correctness.

Hope this helps..

Regards,

Arun Manglick

n-Tier Architecture

2010-11-22T00:32:00.001-08:00

Introduction

1.1 Purpose

This document describes the details of four tier implementation of the new architecture.

1.2 Scope

The scope of this document is demonstrating the four tier implementation of the new architecture.

1.3 Intendent Audience

This document is primarily targeted for the developers and architects working on the Veriphy applications. It provides a useful perspective to other stakeholders such as managers, and the customer.

Overall Description

1.4 Assumptions and Dependencies

1.5 Conceptual Overview

In this scenario, the solution is divided across four separate tiers, or physical machines.

· The client workstation represents first tier that uses a browser application to interact with the Web server.

· The application server represents the third tier with service, business, and data access layers.

· The fourth tier in this design is the database server.

1.6 Tiered Diagram

· Browser interaction with the Web Server uses standard HTTP GET and POST requests.

· The presentation layer uses a request-based / message-based protocol to interact with the service layer.

· The Service Layer uses a Facade call to interact with the business layer.

· Stand-alone ASP.NET Web application that supports basic CRUD operations.

· Presentation and Business logic are distributed across physical boundaries.

· DAL implementation will be implemented using LINQ.

· The application uses data from an existing database schema.

· Tables and views in the database define data structures used by the application

1.7 Another View

1.8 Detailed Tiered/Layered