Tuesday, December 24, 2013

WCF Extensibility

Enter WCF extensibility points.
What is covered:
-          Service description vs Runtime
-          Behavior Interfaces
-          Runtime Extensibility
o   Interceptors
o   Formatters
o   Instancing
o   Error Handling
o   Some Others
-          Metadata Extensibility
-          Serialization Extensibility
-          WCF Channel  Programming Model
What is not  covered:
-          Some lesser-used interfaces
-          Security

Service description vs Runtime
-          Service (client) Description
o   All the things needed to start the service (client)
o   Ednpoints (Address/Binding/Contract)
o   Local Behaviors
-          Before “Open”
o   Description can be changes at will
o   Service not “running”
-          After “Open”
o   Runtime is initialized
o   Description is immutable
o   Listeners are started
o   The Service is started
-          WCF provides 4 interfaces to interact with the Service or Client descriptions
o   Service
o   Endpoint
o   Contract
o   operation
-          Each Interface has 4 methods which follow the same pattern.
-          public interface I[Service/Contract/Endpoint/Operation]Behavior
o   void validate(Description) : Prevent host or client from opening if it finds something invalid in the service description
o   void AddBindingParameters(Description, BindingParameterCollection): This gives an opportunity to the behavior to add more information to the Binding channels.
o   void ApplyDispatchBehavior(Description, Runtime):  This is the place where the behavior gets hooked up  to the runtime in the corresponding scope.
o   void ApplyClientBehavior(Description, Runtime) * {This is only client side}
-          Called during Open (Be it at the service side or the client side)
-          Ordering
o   Validate à AddBindingParameters à  Apply[Client/Dispatch]Behavior
o   Serviceà  Contract à Endpoint à Operation

-          Service Behavior
o   Service-wide operations
§  Metadata : Validation of the metadata exchange across the communication
§  Throttling
§  Debug
o   Public interface IServiceBehavior
§  Validate
§  AddBindingParameters
§  ApplyDispatchBehavior
o   Added via code, configuration, attributes
WCF Runtime   
WCF is a message stack with many message blocks from client calling the operation to the service call getting executed on the server.
We will see the most used blocks through which the messages pass.
·         WCF Runtime
·         Message Object
·         Message Inspectors
·         Parameter Inspector
·         Message Formatters
Client Proxy Call à Parameter Inspector à Fomatter à Message Inspector à WCF stack à Message Inspector à Formatter à Parameter Inspector à Service Operation

First question is what is a Message, what is the structure and Characteristics of the message.?
·         System.ServiceModel.Channel.Message à Abstract Class
·         SOAP/XML
·         Parts
o   Header – Buffered
o   Body
o   Properties : Dictionary not part of SOAP specification
·         Single-use : Once the message is used and read then it cannot be used any more. One can manipulate message headers at will.
·         Message Versions:  different versions of SOAP protocol which are envelopes like SOAP 1.1, 1.2 or none (message is not SOAP message but POX- Plain old XML)
·         XML
Message Inspectors :
Most used WCF extension from the WCF Runtime.
·         Usage: inspect, modify, replace messages
·         Scenarios: Logging, custom auth, tweaking messages, correlation between request and response
·         Server Side
o   MessageInspector is represented by the Interface: IDispatchMessageInspector
§  AfterReceiveRequest
§  BeforeSendReply
o   Dispatch behaviors are typically added as endpoint behavior as a part of ApplyDispatchBehavior to the DispatchRuntime object.
·         ClientSide
o   MessageInspector is represented by the Interface:  IClientMessageInspector
§  BeforeSendRequest
§  AfterReceiveReply
o   MessageInspectores are added as a part of service endpoint to the clientRuntime object.
o   Correlation object Used as correlation so that request can be set with something specific after the prior reply is received.
Parameter Inspector
Parameter inspectors are same as message inspectors but they are called on CLR objects not the message objects. They are easier to use as they do not require any knowledge about messages. Unlike Message inspector they are less powerful as they have less access to message itself.
·         Usage: Inspect and Modify operations inputs and outputs.
o   Return value cannot be modified
·         Scenarios: logging, parameter validation.
·         Same Interface for Client and Server : IParameterInspector
o   IParameterInspector
§  BeforeCall
§  AfterCall
·         Adding parameter inspectors often done in OperationBehavior
o   Server: DispatchOperation
o   Client: ClientOperation
·         Like MessageInspector ParameterInspector has a Correlation object is returned by BeforeCall and Passed to AfterCAll.

Message Formatters
Message formatters are the gateway between WCF messages and world of CLR objects.
·         Usage: convert between CLR objects and Message
·         Unlike Inspectors MessageFormatters are not optional but each operation has one and only one instance MessageFormatter.
·         Scenarios: supporting different formats, like passing some information as a part of httpHeaders.
·         Server Side
o   MessageFormatter is represented by the interface: IDispatchMessageFormatter
§  DeserializeRequest
§  SerializeReply
o   Message formatters can be accessed using the DispatchOperation in the Endpoint and operation behavior.
·         Client Side
o   MessageFormatter is represented by the interface: IClientMessageFormatter
§  DeserializeRequest
§  SerializeReply
o   Message formatters can be accessed using the ClientOperation in the Endpoint and operation behavior.
·         One difference between Inspectors and formatters is that it does not provide the Correlation object between request and reply.

Monday, September 23, 2013

Design Pattern Notes

I have been going through the Design Patterns Library course hosted by Pluralsight. Below is a small descriptions and a note to understand various patterns.

I hope that I should be able to cover all the patterns as the list of patterns are quite extensive and I recommend all of you to get a license of Pluralsight so that you can be exposed to the sea of courses they have. 
(Excuse me upfront for the typos as the notes were taken in notepad++ while I was going through the patterns, once I finish the important patterns I intent to reformat this post and make it more pleasant for all of us)

Adapter Pattern: 
- The Adapter Pattern is used to wrap a needed class with one that implements a required interface. 
- By writing client classes so that they depend on adapters, we future proof these classes, ensuring 
they can be made to work with as-yet-unwritten implementation libraries. 

Related PAtterns to the AdapterPattern: 
- Repository Pattern
- The repository pattern is a verfy common use of Adapter Pattern
- Strategy Pattern
- The adapter pattern is often passsed into a class that depends on it, thus implementing the strategy pattern.
- Facade Pattern
- Adapter and facade pattern are both wrappers. The facade pattern attempts to simplyfy the interface and often wraps many classes, while the Adapter 

typically wraps a single Adaptee, and is not generally concerned with simplyfying the interface.

Bridge Pattern: 
DEcouple an abstraction from its implementation so that 2 can vary independently. Abstractions and implemenation are decoupled. 

Abstract one more level of interface so that 1st level of abstraction is dependent on the 2nd level of abstraction 

This abstraction is going to use one more level of Abstraction as its implementation.\

Abstraction -> Abstraction -> Implementation 

For one level of abstraction there's no need of Bridge pattern. 
Common usgaes of bridge pattern: 
- User Interfaqce 
- Neat explanantion of the pattern is also given at:

Builder Pattern: 
Problem 1: too Many paramteres
Problem 2: Order Dependent
Problem 3: Different Constructions

Spearates the construction of a complex object from its representation so that same construction process can create different representations. 
Construction of the object is a process OR logic.
Representation of the object is data. 

Separate logic from data, reuse the logic to produce different data. 

Instead of telling the subway guy on what all you need after asking for each ingredient you are going to give him an list of ingredients so that the conversation is 

much shorter. 

Chain of Responsibility Pattern: 
Provides a simple mechanism of decoupling the sender of the message from the receiver 
Ordered list of methods 

Sender --> Receiver1 --> Receiver2 --> Receiver3 

Lets say in the above scenario the message sent by the sender is handled by the Receiver2 and so the receiver 3 is not needed.
Sender only is exposed to the Receiver1 and so is the Receiver2 knows only about Receiver3. This brings us to the traits of Chain of Responsibility. 

- Sender is aware of only one receiver 
- Each receiver is only aware of the next receiver
- Receivers process the message or just send it down the chain
- The sender does not know who received the message.
- The first receiver to handler the message terminates the chain
- The orcer of the receiver list matters

Command Pattern: 

- A command line order management system
- A system in which you pass in a command to be done. 
- In such systems we should be wary of a very big switch case statements which decide what to do based on the input passed.

Intent of the PAttern: 
- Represent an action (piece of logic) as an object
- DEcouples the clients that execute command from the details and dependencies of the command logic
- Enables delayed execution 
- Can queue command for later execution 
- If command objects are also persistent, can delay acrosds the process restarts

Also knows as Action OR Transaction PAttern
Applicable on 
- Logging the actions 
- Validation 
- Undo functionality in the website 

Client --> Command { Validate(), Execute(), Undo()} --> (dependencies)
  --> (dependencies)

- Key notion of command pattern is that somebody can call a method without dealing with any extra data.
- There is no parameter to be passed which makes it different from the Strategy pattern (here execution path is defined based on the parameter passed)
- COmmands must be completely self contained 
- The client does not pass in any argumemnts, the context from the caller is not required 
- Easy to add new commands (open/closed principal)

Related Patterns: 
- Factory pattern : Factories are ofyten useful to construct the command objects 
- Null Objects: Often times returning a "null command" can be useful instead of retuning a null
- Composite Command: Command with child commands

Composite Pattern: 
- Compose objects into tree structures to represent part-whole hierarchies. 
- Composite lets clients treat indivisual objects and compositions of objects uniformly. (GOF)
- If you are sending emails to individuals instead of using the group aliases then you need to apply composite pattern to your life. 
- Using group aliases is the live example of using the composite pattern, the sends just sends an email to the group and the e-mail has the logic to iterate over the 

members of group and make sure that email is individually sent to each of the member.
When to Use Composite Pattern: 
- When you have groups and collections 
- Can you add an Interface
- trees
- Distribution 

Basic is to define an interface (component) and have a leaf (simple object implement it) and then create a composite object which implements the interface and also has 

a property which is of the type of component.

Decorator Pattern: 

Structural Pattern : DEcorator object is used without touching the existing class. 

Small Pizza company: Large, Medium and Small Pizza deriving from Base class Pizza. 

Problem is when toppings are introduced: Cheese, Ham and Peppers

Now with 3 Pizzas we have 3 toppings each combination is a unique pizza. 
This will result in class explosion and will become very hard to maintain. 

- Add functionality to existing objects dynamically at runtime without effecting the other classes. 
- Alternative approach to sub classing 
- Inheritance based design leads to an explosion of the classes.
- Flexible design 
- Support Open Close Principle --> Open for extension but closed for modification 

- Legacy systems 
- Add functionality to controls. 
- Sealed Classs

IExtenderProvider interface uses decorator pattern, for more info on the interface below are the links:

How does it work: 
- It wraps the object -- Also known as wrapper object 

Lazy LOad Pattern: 

Lazy Initialization Pattern : 

- Simplest approach 
- Every property checks to see if its backing firlds has been initialized 
- If so it calculates or fetches the value for the field before retunung.
- Violates don't repeat yourself principle 
- Requires all access to tge value ti go through the property
- Within the class nothing but the property should access the field. 
- Requires knowledge of whether the fields has been calculated
- Typically check if the field is null
- If null is a legal value then another approach is required, like using the flag if the value is populated or not. 

Virtual Proxy Pattern: 
- Proxy looks like real object
- Creates Indentity problem in the application 
- Proxy isn't the real object 
- OverRide the equality method (Equals)
- Proxy Design PAttern
- May need to create many virtual proxies
- Best done via some kind of code generation 
- MAny OR/M tools create dynamic proxies at runtime (nHibernate, Entity Framework)

Virtual Proxy Consequences: 
- Managing Identities can present Challenges --> Overriding GetEquals and GetHashCode 
- Need to create many virtual proxies, one for each class that is proxied
- Above stated points are not present for collections: 
- Collections are value objects and do not have an identity.
- Typically there are fewer collections than objects 
- Collections typically provide largest performance benefit from the lazy loading. 

Value Holder LAzy Load PAttern: 
--> No need to use this if we are using .Net 4.0 if .Net 4.0 is in use then directly use Lazy
-  Provides lazy load functionality without encapsulation which means the client knows about the lazy loading. 
- Calling code knows it is working with a Value Holder  type 
- Requires creating several new Types: 
- Value Holder 
- IValueHolder 
- Factory or MapperClasses
- Value Holder uses IValueHolder via Strategy Pattern to load value when accessed.
- ValueHolder and IValueHolder are resuable
- ValueHolder is similar to Lazy and IValueHolder is similar to the lambda expression which is passed which knows how to load the lazy type. 
- ValueHolder and IValueLoader are resuable.

Ghosts Pattern: 

- A ghost is a real object in a partial state.
- An object which knows about its own state. 
- Intially ghost contains its Id.
- Whenever any property is accessed, the ghost class loads all of its state from persistence. 
- Essentially, the object is its  own virtual proxy
- Avoids identity concerns of its own virtual proxy,
- This violates the Single responsibility cause the object is needed for self loading and plus loading the state of its own properties. 

Mediator PAttern: 
Motivating Example
- When you have many objects of a similar typpe that need to communicate with each other 
- The communication between objects is complex
- Define an object that encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly,
and it lets you vary their interaction independently. 

Components in Mediator Pattern: 
- Colleagues 
- Individual compnents that need to communicate with each other Airbus, Fighter 
- Implement the same base type(abstract class or interface)
- HAve a knowledge of the Mediator component rather than knowing of each other. 
- Mediator 
- Single centralized component that managed communication between the colleague components
- abstraction of mediator is necessary so that the colleagues work with the abstracted mediator rather than concrete one. 

- Hides all the coordination between colleagues 
- Decoupled colleagues 
- Mediator's one to many relationship with colleague is preferred to colleagues relating in a many-to-many fashion.

- The mediator can become very large and very complicated as more colleagues are handled. 

Overall mediator enhances decoupling 

Memento Pattern: 

Undo and Redo functionality 
Motivating Example: 
- It would be useful to rollback one or more objects within your application to previous state(for example, to implement Undo)
- Providing undo functionality within one or more calsses would violate the single responsibility principle 
- Providing full access to objects internal state violates the encapsulation principle
- The Memento pattern describes a way to capture the objects internal state without violating encapsulation or SRP. 

- Without violating the encapsulation, capture and externalize an objects internal state so that the object can be restored to this state later. 
- The memento pattern involves 2 objects : originator and caretaker. Thr originator represents object whose state is being tracked.
The care taker performs the operation on the originator but needs to be able to undo operations. 

Applicability: When to use the Memento Pattern: 
- in case of an application whose state needs to be tracked, you need to be able to track the state of an object or your application and restire previous states as 

- You want to abstract and reuse the Undo/Redo functionality
- Follow SRP and Don't repeat yourself
- You do not wish to break encapsulation and expose your classes internal state globally 

How the memento is used: 

- Memento itself holds the state of the originator 
- Ideally ony the originator should have access to the internal details of its state within the Memento
- The caretakers interface to Memento should not allow it to access the internal state of the Originator
- The originator can create Mementos or restore its given state given a Memento
- The care taker maintains the memento objects without operating on their contents. 

Common Usage of Memento is Undo and Redo functionality: 

- Multiple Undo/Redo is often implemented using a stack
- When a change is performed:
- A memento containing the current state is added to the Undo stack
- When an undo operation is performed: 
- the current state is replaced with the state of the memento removed from the Undo stack 
- If Redo is implemented, the current state is stored in a Redo stack.
- When a Redo operation is performed
- The current state is replaced with the state of the memento removed from the Redo stack
- The current state is stored in the Undo stack.


- Whenever a change is made from the requested state, A care taker requests a Memento from the Originator
- The caretaker stores one or more Mementos until they are needed. 
- If or when requred the Caretaker passes the Memento back to the originator
- It may be possible that Memento stored by caretaker may not be used if there is no redo or undo functionality 
- Mementos should be value objects, holding state but no behavior. 
- Only the originator which created a memento should be able to assign or retreive its state. 

Model View Presenter Pattern: 

Model View View Model Pattern:

- a set of guidelines to code for an application
- Where did MVVM come from?
- What is MVVM?
- Components of MVVM ?

- 2004 Martin Fowler - Presentation Model
- Separates a view from it's state and behavior
- Not dependent on specific UI Framework
- 2005 John Gossman unveiled the MVVM pattern
- Tailored for WPF and Silverlight platforms

- Separate Concerns
- View
- View's state and Behavior
- Data
- Unit testing and UI testing
- Maintenance
- Extensibility
- Enables designer/developer workflow
- Take advantage of WPF/silverlight databinding --> Also supports input validation

- View
- ViewModel
- Model

- Model :
- HAs no reference to the View or ViewModel
- Model can be represented by Domain specific objects
- Model can be represented as Data centric object (model is XML or data access layer)
- Model's purpose is to represent Data points
- ITs single purpose is to represnt datapoint
- View :
- May or Maynot have a reference to the ViewModel
- Doesnot have a reference to the Model
- It consists of only visual elements of display like buttons windowns and everything
- Responsible for showing and collection data to and from user.
- in silver light the data bindings are specified but the details are hidden from the UI.
- Binding the viewModel set by DataContext
- The ViewModel:
- Has a reference to the Model
- May or may not have a reference to the view
- Contains properties and commands  and other abstratctions to make the communication easy between the view and the model.
- At minimum the view should implement the INotifyChanged interface because the ViewModel is bound to notify the view of a change.
- Although the ViewModel contains the state and the data for the UI is should have a UI control as a base object.

To Create the connection between the view and viewModel (Binding the view to ViewModel):
- Declaratively in XAML --> View first approach --> ViewModel as a resource --> Static resource on the View
- Cannot control instantiation
- Cannot pass parameter
- Imperatively in code
- The view model is assigned in the views code behing after the Initialization method
- View Model Locator --> Service Locator renamed for MVVM
- DataTemplates
- Inversion of Control
- Factory with Inversion of Control
- and more ..

- Events
- Commands
- Execute
- CanExecute

- Pro:
- Reduce Code behind
- Model doesnot need to change to support a view
- Designers design and coders code
- Reduces development time
- Multitargeting and project linking
- Create more files
- Simple tasks can be complicated
- Lack of standardization
= Specific to WPF and Silverlight platforms 

Prototype Pattern:
- Overview of the Prototype PAttern
- SPecify the kinds of objects to create using a prototypical instance and create new objects by

copying this prototype --> Cloning or Making a copy instead of newing the object up
- Its easier to make a copy of the object than going through the whole construction process this is why

this pattern is used.
- Problem 1: COnstruction cost of an object is expensive
- Problem 2: State is important copy the state.
- Problem 3: Hiding the constructor
- Prototype design --> Just implement a Icloneable Interface and while implementing Clone method return

- You can do a deep copy and shallow copy --> MemberwiseClone does only shallow copy is specified only at one

- Examples are present in javascript, javascript is a prototypical language. --> Structuring Javascript is a

course on pluralsight.

Friday, September 13, 2013

String.Intern Method

The common language runtime conserves string storage by maintaining a table, called the intern pool, that contains a single reference to each unique literal string declared or created programmatically in your program. Consequently, an instance of a literal string with a particular value only exists once in the system.

Definition taken from:

Tuesday, August 06, 2013

Service Stack : Solution to cross platform services

I have MSDN Magazine Reader 4 Android app which helps me read the latest msdn magazine.

I came across an article which talks about the ServiceStack, The article neatly and simply describes a brief POC on what can to be done with Service Stack. 

Link to the article:

To my surprise there's already a course on Pluralsight named: Using ServiceStack to Build APIs 

Will go through the course soon and post my thoughts on that too. 


Wednesday, July 10, 2013

Design Principle Learning

I am brushing up my fundamentals on SOLID principles, by going through the pluralsight course named: SOLID Principles of Object Oriented Design

The author of the course Steven Smith has done an amazing job here kudos to him.

Tell don't Ask:

Don't interrotgate objects for their internals -- move behavior to the object.
Tell the object what you want it to do.
Consider Refactoring to a new Base Class
 - Given 2 classes share a lot of behavior refactor them to a base class

Interface segragation principle: 

- Clients should not be forced to depend on methids they do not user. 
- Prefer small, cohesive interfaces to fat interfaces 
- Interface Segragation principle violations result in classses that depend on things they do not need,
increasing coupling and reducing flexibility and maintainability. 

- Unimplemented Interface methods
- Client references a class but only uses a portion of it. 
- If you find yourself depending on a fat interface you own
- if you find fat interfaces are problematic but you don't own them 
- Create a smaller interface with what you need 
- Implement this interface using an adapter that implements the full interface. 

Dependency Inversion Principle PART I: 
- Highlevel modules should not depent on lowlevel modules. both should depend on abstractions.
- Abstractions should not depend on details rather details should depend on abstractions.
- What are the depdendencies ?
- Framework is a dependency, ohter dependencies are third party libraries, Database, File system, Email, Webservices, System Resources, configuration, the new keyword (this means direct dependency), Static methods, thread.sleep, Random(difficult to test if the code uses Random instead use a inteface to generate random so that during testing its possible to make sure that random returns the expected value by mocking and faking the objects)
- Classes dependencies should be honest
- Classes whose constructors make this clear are called as explicit dependencies
- Classes that do not have impplicit or hidden dependencies
- Classes should declare on what they need. 

Dependency Injection : is a technique that is used to allow calling code to inject the dependencies a class needs when it is instantiated. 

The hollywood principle: Don't call us; we'll call you.
The techniques: 
1. Constructor Injection : Strategy Pattern
- Classes self document on what they need to perform ofr their work
- Works well without a container
- Classes are always in a valid state once constructed
- Constructors can have many parameters/dependencies
- Some features may require default constructor.(Serialization)
- Some methods in the calls may not require things other methods require but the    constructor injection. 
makes all the dependencies available for all the methods which is a design smell.
2. Property Injection: Setter Injection
- Dependencies can be changed at any time during the lifetime of the object
- Very flexible
- Objects may be in invalid state between the construction and seetion of dependencies via setters
- Less intuitive
3. Parameter Injection: dependencies are passed in via a method parameter 
- Most Granular
- very flexible
- Requires no change to the rest of the class
- Breaks method signature
- Can result in many parameters
Consider if only one method has the dependency otherwise prefer constructor injection. 
How to refactor to achieve dependency inversion principle; 
- Extract dependencies to Interfaces
- Inject Implementaytion of interfaces into order
- Reduce Orders responsibility (apply SRP)

Design Smells which can be addressed via Dependency Inversion principle 
- Use of new Keyword
- Use of Static method and properties 
- Good way of using static method is the place where there is no dependency in the method apart from the parameters which are being passed
- static methods should not instantiate other classes which might have dependencies of their own then it becomes a problem.

Where do we instantiate the objects: 
- Default Constructor 
- Startup of the application or the main method of the application. 
- Use an IOC container.

IOC Containers: 
- Responsible for object graph instantiation
- Inititated at application startup via code or configuration
- Managed interfaces and the implementation to be used are Registered with the container
- Dependencies on interfaces are Resolved at application startup or runtime. 

Dependency Inversion Principle PART II: 

- Traditional application architecture follows the model where in we have UI --> BLL --> DAL
- The problem with such a design is that the dependencies flow towards the Infrastructure 
- Core/Business/Domain classes depend on the Implementation details.
- This results in tight coupling 
- No way to change implementation details without recompile(OCP violation)
- Difficult to test
- Dependencies is transitive
- If UI depends on BLL depends on DAL depends on DB. Then everything depends on database.
- Depend on abstraction

Don't Repeat Yourself : 
- Every piece of knowledge must have a single, unambiguous representation in the system.
- Repetition of logic calls for abstraction. Repetition of process calls for automation. 
- Once and only once 
- Duplication is Evil 
- Use of Magic strings
- Duplicate logic in multiple location
- Repeated if then logic in the code 
- Applying DRY to remove magic string 
- assign the magic string to a variable or in config file, this is just to avoid the repetition of value of connection string 
- if then logic can be moved into a loop 
Related fundamentals: 
- Template method
- command pattern
- Depdendency Inversion principle