Posts Tagged ‘Design Patterns’

There can be many UI / API / DB level design patterns to follow but when / what to choose need to be carefully decided and following 5 important principals helped to decide on some of the recent decisions … (Thanks to our Chief Architect for providing these guidelines …)

  1. Keep original data
  2. Maintain SVOT – strengths, vulnerabilities, opportunities, threats
  3. Follow KISS – Keep It Simple Silly – easy maintenance / low cost / more reliability
  4. Don’t rely on PUSH
  5. Plan for disaster

Here are the examples of how above principles are helped us to decide between PUSH Vs PULL  &  Filtering out the data or Keeping the original msg …

Our team had created multiple microservices recently for achieving a big org level new initiative. For one of the end to end flow i.e. creating a new app instance for a trail user involves 3 microservices which follows #1, #4 from above principals.

  1. External Service – follows the event lifecycle model where it triggers the subscribed REST endpoint with user request msg when a new user request comes. Here event lifecycle can be synchronous/asynchronous and the service tries multiple times in case when REST endpoint is down. The service also expects REST endpoint to complete the event lifecycle.
  2. REST interface service – gets the msg from external service and pushes it into ZK.
    1. Follows #1 so that the “Original message” been “PUSHed” to  ZK so that it avoids unnecessary parsing/transformations on the msg, operation will be quick & future changes on the msg can be directly synched instead of parsing/editing the zk msg.
    2. Here #4 is not followed since the service been triggered by external service which intern pushes the original message to ZK and it wait for the core service to complete the provisioning and core service updates the status to ZK. Once it gets the provisioning status by following #4 i.e. PULL model  it triggers the external service to complete the event life cycle.
  3. Core service which I owned creates application instances in Docker Swarm for the trail customers based on data provided in Zookeeper (ZK)
    1. Zookeeper out of box provides watch capability where we can watch on a node which triggers an event when changes happen and based on that the core service can take care the provisioning, so it is PUSH model. But here based on #4, we followed the PULL model i.e. pulling ZK data in period interval to take care provisioning requests and it really helped us from single point failure with ZK (i.e. ZK connection failure or missing some of the events due to any exceptions).

 

Design Pattern References:

Advertisements

http://microsoftnlayerapp.codeplex.com/

http://msdn.microsoft.com/es-es/architecture/en/

Define all your functions and variables in the private scope and return an anonymous object at the end of the module with pointers to the private variables and functions you want to reveal as public. Check more @

http://www.wait-till-i.com/2007/08/22/again-with-the-module-pattern-reveal-something-to-the-world/

Ex: Singleton pattern using Revealing Module Pattern

var singleton = function () {
var privateVar = 10;
function privateMethod1() {
return privateVar;
};
function SetVal1(val) {
privateVar = val;
};
function GetVal1() {
return privateVar;
};
function GetVal2() {
return privateMethod1();
};
return {
SetVal1: SetVal1,
GetVal1: GetVal1,
GetVal2: GetVal2
};
} ();

var obj1 = singleton;
var obj2 = singleton;
alert(obj1.GetVal1());
obj1.SetVal1(20);
alert(obj2.GetVal1());

var singleton = function () {
var privateVar = 10;
function privateMethod1() {
return privateVar;
}

return {
SetVal1: function (val) {
privateVar = val;
},
GetVal1: function () {
return privateVar;
},
GetVal2: function () {
return privateMethod1();
}
};
} ();

var obj1 = singleton;
var obj2 = singleton;
alert(obj1.GetVal1());
obj1.SetVal1(20);
alert(obj2.GetVal1());

http://msdn.microsoft.com/en-us/scriptjunkie/hh297451.aspx

http://msdn.microsoft.com/en-US/scriptjunkie/hh273390.aspx

1. Centralized event handling

This will be used in cases where we have a number of similar elements or structures on a page that share similar behaviour when a user-action is performed against them.

In JavaScript, there’s a known bubbling effect in the language so that if an element such as a link or button is clicked, that event is bubbled up to the parent, informing them that something lower down the tree has been clicked. We can use this effect to our advantage.

Ex: In following example we can bind click event to ul and can handle every li click separately with out binding different functions directly to each li. This will also improve performance by minimizing the DOM access for binding/unbinding and by avoiding the event handling for each element separately.

<ul>
 <li class=’one’>One</li>
 <li class=’two’>two</li>
 <li class=’three’>three</li>
 <li class=’four’>four</li>
 <li class=’five’>five</li>
</ul>

stateManager = {
    fly: function () {
        var self = this;
        $(‘ul’).unbind().bind(“click”, function (e) {
            var target = $(e.originalTarget || e.srcElement);
            if (target.is(“li.one”)) {
                self.handleLIOne(target[0]);
            }
            else if (target.is(“li.two”)) {
                self.handleLITwo(target[0]);
            }
        });
    },
    handleLIOne: function (elem) {
        //Do your own implementation for first li element click
        alert(elem.innerHTML);
    },
    handleLITwo: function (elem) {
        //Do your own implementation for second li element click
        alert(elem.innerHTML);
    }
}
stateManager.fly();

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace DesignPatterns.PubSub
{
[TestClass]
public class TestSample
{
[TestMethod]
public void Main()
{
Publisher publisherService = new Publisher();
Subscriber1 sub1 = new Subscriber1(publisherService);
Subscriber2 sub2 = new Subscriber2(publisherService);

publisherService.Publish(“Published”);
}
}

public class Publisher
{
public delegate void PublishDelegate(object sender, InfoArgs args);
public event PublishDelegate PublishEvent;

public void OnPublishEvent(object sender, InfoArgs args)
{
if (PublishEvent != null)
PublishEvent(sender, args);
}

public void Publish(string info)
{
OnPublishEvent(this, new InfoArgs(info));
}
}

public class InfoArgs : EventArgs
{
private readonly string info;

public InfoArgs(string info)
{
this.info = info;
}

public string Info
{
get { return info; }
}
}

public class Subscriber1
{
private Publisher publisher;
public Subscriber1(Publisher pPublisher)
{
this.publisher = pPublisher;
pPublisher.PublishEvent += Action;
}

static void Action(object sender, InfoArgs args)
{
Console.WriteLine(“Subscriber1 Action: ” + args.Info);
}
}

public class Subscriber2
{
private Publisher publisher;
public Subscriber2(Publisher pPublisher)
{
this.publisher = pPublisher;
pPublisher.PublishEvent += Action;
}

static void Action(object sender, InfoArgs args)
{
Console.WriteLine(“Subscriber2 Action: ” + args.Info);
}
}
}

Reference –

http://www.akadia.com/services/dotnet_delegates_and_events.html

http://www.dotnetarchitecthouston.com/post/The-Publish-Subscribe-Pattern-in-C-and-some-gotchas.aspx

http://msdn.microsoft.com/en-us/library/ms752254.aspx – WCF

http://msdn.microsoft.com/en-us/library/ff649664.aspx – MS Patterens & Practices