Sunday, July 26, 2015

Self Hosting of WCF Service

WCF service can be hosted with IIS, Self hosting & WAS server.

Self Hosting : In self hosting of WCF service we can host the service in our own application domain.
Whole WCF service can consists in an assembly, as you run the application (assembly) service got started and can be accessed.

Port you are using for service should not be in use by other IIS site and this port should be open on server in order to access it publicly.



Source Code:


Self hosting class
namespace ConsoleApplication1
{
    public class clsSelfHosting
    {
        static void Main(string[] args)
        {
            ServiceHost host;
            Uri uri = new Uri("http://localhost:1300/MyWCFSelfHosting");

            host = new ServiceHost(typeof(ConsoleApplication1.Service1), uri);
            host.AddServiceEndpoint(typeof(IService1), new WSHttpBinding(), "");

            ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
            smb.HttpGetEnabled = true;
            host.Description.Behaviors.Add(smb);
            host.Open();
            Console.WriteLine("Service Started...");
            Console.ReadLine();
        }       
    }
}

Sunday, July 12, 2015

Service Oriented Architecture (SOA)

Service oriented architecture is an architecture style provides a way of making business applications using loosely coupled architecture of services.

SOA stands on services and communication between services using standard messages.

Services: A services is self contained & self-explanatory business logic accessible across platforms.

Services should be –
  • Self contained business logic
  • Self-explanatory
  • Hosted to be discovered by any one in web world 
  • Accessible on any platform in web world 

Messages: Messages are standard format text that is readable across platforms to communicate among services.

Messages should be –
  • Standard
  • Understandable across platforms in web world
  • Able to explain services


Saturday, July 11, 2015

Memento Design Pattern

Memento pattern is a way to preserve internal state of an object without violating encapsulation.

It is a widely used behavioral pattern.

There are three section of this pattern

Originator:
This is the original object for that memento get created
Memento: This is the copy of original class to preserve the original state of originator object.
Care Taker: This object holds memento object to restore to originator at any point of time.


Requirement:
During changing of object state if something goes wrong, object can be reverted to original state.

Use:
Original state can be re-stored at any point of time during application running.

Problem Solved:
Generally when required people restore object to its original state from database. So by using this pattern no need to query database to restore object.


Sample Code:

    
/// <summary>
    /// Original class
    /// </summary>
    public class Origintor
    {
        private string name;
        private string mobile;
        private string eMail;

        public Origintor(string _name, string _mobile, string _email)
        {
            name = _name;
            mobile = _mobile;
            eMail = _email;
        }

        public string Name
        {
            get
            {
                return name;
            }
            set
            {
                name = value;
            }
        }

        public string Mobile
        {
            get
            {
                return mobile;
            }
            set
            {
                mobile = value;
            }
        }

        public string Email
        {
            get
            {
                return eMail;
            }
            set
            {
                eMail = value;
            }
        }

        public Memento SaveMemento()
        {
            return new Memento(name, mobile, eMail);
        }

        public void RestoreMemento(Memento objMemento)
        {
            this.Name = objMemento.Name;
            this.Mobile = objMemento.Mobile;
            this.Email = objMemento.Email;
        }
    }

Builder Design Pattern

The intent of this pattern is to separate construction of an object from its representation, so the same construction process can create different representation.

Its a creational design pattern.
Separates presentation of an object from its construction process.

There are three sections of this pattern:
  • Builder: Builder is responsible for defining construction process of each individual part of product. Builder has these small construction processes in it. 
  • Director: Director calls concrete builder of product as per client requirement.
  • Product: Product is final product that have multiple forms depends on which builder created the product.

Requirement: Whenever we have to create same kind of products with something different representation, we need this pattern.

Use: We can create different products using same construction process.

Problem Solved:  For creating products having different representation, no need to create whole separate process for each.



Sample Code:


    public class ReportDirector
    {
        public ReportDirector()
        {
        }

        public Report CreateReport(ReportBuilder reportBuilder)
        {
            reportBuilder.SetReportType();
            reportBuilder.SetReportTitle();
            reportBuilder.SetReportHeader();
            reportBuilder.SetReportFooter();
            return reportBuilder.GetReport();       
        }

    }

Friday, July 10, 2015

Abstract Factory Pattern

Provides a way to encapsulate a group of individual factories those have common theme (related) without specifying their concrete classes.

  • Its an important creational pattern
  • Abstract factory is an extension on factory pattern


Requirement: If you have created many factories or looking to create, client code become complex and scattered to call many factories. In that case abstract factory provides a centralized & simple way to call different individual factories using abstract factory.
Client only knows about Abstract factory & calls only Abstract factory for all individual factories.

Use: Client is able to call different related concrete factories from a single point of contact.
Client doesn't know about concrete classes & concrete factories. Client is aware only with abstract factory & abstract products (Interfaces).

Problems Solved: New concrete factories with related theme can be added without updating client.







































Sample Code:


    public abstract class AbstractFactory
    {      
        /// <summary>
        /// Get Connection Factory
        /// </summary>
        /// <param name="connectionType">
        /// 1- Sql Connection
        /// 2- Oledb Connection
        /// </param>
        /// <returns></returns>
        public abstract Connection GetConnectionObject(int connectionType)
        {
           return (new ConnectionFactory()).GetConnectionObject(connectionType);
        }

        /// <summary>
        /// Get Command Factory
        /// </summary>
        /// <param name="commandType">
        /// 1- Sql Command
        /// 2- Oledb Command
        /// </param>
        /// <returns></returns>
        public abstract Command GetCommandObject(int commandType) 
        {
           return (new CommandFactory()).GetCommandObject(commandType);
        }
     }

CI/CD - Safe DB Changes/Migrations

Safe DB Migrations means updating your database schema without breaking the running application and without downtime . In real systems (A...