An Implementation of Unity of Work and Repository Pattern

 

Objective:

1. Keep a clean separation of concerns.

2. Implement business logic from acceptance test/ use case ( ATDD/ BDD )

3. A complete implantation on Repository and Unit of Work with IoC and Unit Testing (BDD).

.

Unity of Work Pattern:

One of the most common design patterns in enterprise software development is the Unity of Work. According to Martin Fowler, the Unity of Work pattern “Maintains  a list of objects affected by a business transaction and coordinates the writing out of changes and resolution of concurrency problems".

In a way, you can think of the Unit of Work as a place to dump all transaction-handling code. The responsibilities of the Unit of Work are to:

• Manage transactions.
• Order the database inserts, deletes, and updates.
• Prevent duplicate updates. Inside a single usage of a Unit of Work object, different parts of the code may mark the same Invoice object as changed, but the Unit of Work class will only issue a single UPDATE command to the database.

The unity of work pattern isn't necessarily something that you will explicitly build yourself, almost every persistence tool already aware of it. The Entity Framework also have implementation of Unity of Work. SaveChanges() give us feature of unity work. Which allow us to save changes of list of objects together into database. But As I want decouple my business logic from database so the implementation of Unity of Work is

 

1 public interface IUnityofWork : IDisposable 
2 
3 { 
4 
5     void Commit(); 
6 
7 } 
8 
9 

The Commit() function work same as SaveChanges() in EntityFramework. If we use update records through context directly then we do not need really to maintain transaction but as we also have some existing stored procedure need to call and also for  bulk copy operation, we also need to maintain transaction explicitly. 

The implementation of Unity Of Work for Entity Framework as

 

 1  1 public class UnityOfWorkBase
 2  2 {
 3  3     private bool _disposed = false;
 4  4     protected DbContext Context;
 5  5     public void Commit()
 6  6     {
 7  7         Context.SaveChanges();
 8  8     }
 9  9     public void Dispose()
10 10     {
11 11         Dispose(true);
12 12         GC.SuppressFinalize(this);
13 13     }
14 14     protected virtual void Dispose(bool disposing)
15 15     {
16 16         if (_disposed)
17 17         return;
18 18         if (disposing)
19 19         {
20 20             if (Context != null)
21 21              {
22 22                Context.Dispose();
23 23                Context = null;
24 24              }
25 25         }
26 26         _disposed = true;
27 27     }
28 28     
29 46 }

 

Repository Pattern

Unity of Work provided me decoupling from database operation which we do not need to implement for Unit Testing scenario.

Next for decoupling database entity I have created repository for each entity which provide common functions as in memory object like List.

According to Martin Fowler, “Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects”.

Repository act-like in memory collection like List for .NET which provide common function like Add(), Remove(),  and enumeration functionality.  LINQ also provide extensive functionality on List and also Entity framework. 

The generic implementation of Repository pattern as follows:

 

 1  1 public interface IRepository<T> where T : class
 2  2     {       
 3  3         IQueryable<T> Query();
 4  4  
 5  5         IEnumerable<T> FindAll();
 6  6  
 7  7         IQueryable<T> Find(Expression<Func<T, bool>> predicate);
 8  8           
11 11         T First(Expression<Func<T, bool>> predicate);      
12 12  
13 13         void Add(T entity);
14 14         void Add(List<T> entity);
15 15  
16 16         void Delete(T entity);
17 17  
18 18         void Attach(T entity);
19 19  
20 20         bool BatchInsert(IList<T> entity, string tableName);
21 21  
22 22     }

BulkCopy is faster than normal insertion of multiple records as a batch. So in the repository I also have provided implementation. This implementation is suitable for both List and also DbSet.

The implementation of Repository for unit testing as follows:

 

 1  1 public class TestRepository<T>:IRepository<T> where T:class
 2  2     {
 3  3         private IList<T> _repostiory = new List<T> ();
 4  4         public IQueryable<T> Query()
 5  5         {
 6  6             return _repostiory.AsQueryable();
 7  7         }
 8  8  
 9  9         public IEnumerable<T> FindAll()
10 10         {
11 11              return _repostiory;
12 12         }
13 13  
14 14         public IQueryable<T> Find(Expression<Func<T, bool>> predicate)
15 15         {
16 16             return _repostiory.AsQueryable().Where(predicate);
17 17         }
18 18  
19 19           
24 24         public T First(Expression<Func<T, bool>> predicate)
25 25         {
26 26             return _repostiory.AsQueryable().FirstOrDefault(predicate);
27 27         }
28 28  
29 29         public void Add(T entity)
30 30         {
31 31             _repostiory.Add(entity);
32 32         }
33 33  
34 34         public void Add(List<T> entities)
35 35         {
36 36             foreach (var entity in entities)
37 37             {
38 38                 _repostiory.Add(entity);
39 39             }
40 40         }
41 41  
42 42         public void Delete(T entity)
43 43         {
44 44             _repostiory.Remove(entity);
45 45         }
46 46  
47 47         public void Attach(T entity)
48 48         {
49 49             throw new NotImplementedException();
50 50         }
51 51  
52 52         public bool BatchInsert(IList<T> entities, string tableName)
53 53         {
54 54             Add(entities.ToList());
55 55             return true;
56 56         }
57 57     }

In the TestRepository example the repository is a in memory List object.

This repository is suitable for tables and views. But As we already have existing implication and some logics are in database. So I need to provide an interface to call stored procedure as well.

Repository for stored procedure will provide common function to execute stored procedure and retrieve value.

The interface of repository for stored procedure as

 

1 1 public interface IRepository_SP<T>
2 2     {
3 3         IEnumerable<T> ExecSqlQuery( params object[] parameters);
4 4         Int32 ExecSqlCommand(params object[] parameters);
5 5     }

The implementation of IRepostory_SP for unit testing is also simple as for query records it should return List and for executing command it return 0.

 

 1  1 public class TestRepositorySp<T> : IRepository_SP<T> where T:class
 2  2     {
 3  3         public List<T> Items { get; set; }
 4  4  
 5  5         public TestRepositorySp(List<T> items)
 6  6         {
 7  7             Items = items;
 8  8         }
 9  9  
10 10         public IEnumerable<T> ExecSqlQuery(params object[] parameters)
11 11         {
12 12             return Items;
13 13         }
14 14  
15 15        
16 16         public int ExecSqlCommand(params object[] parameters)
17 17         {
18 18             return 0;
19 19         }
20 20     }

 

The example for mocking the stored procedure

1  var mocksecuritySp = new Mock<IRepository_SP<int>>();
2             mocksecuritySp.Setup(e => e.ExecSqlCommand(It.IsAny<ObjectParameter>()))
3                 .Returns(0);
4             _testUnityOfWork.DeleteCommandRepositorySp = mocksecuritySp.Object;

This article is based on article https://msdn.microsoft.com/en-us/library/ff714955.aspx.

I wrote article on Specflow and FluentAssertion long time ago. Here is the link

http://ciintelligence.blogspot.ca/2014/05/atdd-acceptance-test-driven-development.html

Code Smells: Long Method Refactoring using Resharper

The object programs that live best and longest are those with shorts methods.  Programmers new to objects often feel that no computation ever takes place, that object programs are endless sequences of delegation.

     Since the early days of programming people have realized that the longer a procedure is, the more difficult  it is to understand. Modern OO languages have pretty much eliminated overhead of in-process calls.There is still overhead to the reader of the code because you have to switch context to see what sub procedure does. But the real key to making it easy to understand small method id good naming. If you have a good name for a method you don't need to look at the body.

Refactoring:

     A heuristic we follow is that whenever we feel that need to comment something, we write a method instead. Such a method contains the code that was commented but is named after the intention of the code rather than how it does it. This is also the way to refactor "Comments" code smell.

Ninety-nine percentage of the time, all you have to do to shorten a method is Extract Method . Find parts of the method that seem to go nicely together and make a new method.

If you have a method with lots of parameters and temporary variable  the you can follow the approach I mentioned in another article

Refactoring Long Parameter List:

I have already written an article on refactoring long parameter list : http://ciintelligence.blogspot.com/2015/09/code-smells-long-parameter-list.html . If you've tried that, and you still have too many temps and parameters, its time to get out the heavy artillery Replace Method with Method Object.

 

Extract Method :

Extract method is one of the most common refactoring I do.  I look at a method that is too long or look at code that needs a comment to understand its purpose. I then  turn that fragment of code into its own method.

     Mechanics:

• Create a new method, and name it after the intention of the method ( name it by what it does, not by how it does it)
• Copy the extracted code from the source method into the new target method.
• Scan the extracted code for references to any variables that are local in scope to the source  method. These are local variables and parameters to the method.
• See whether any temporary variables are used only within this extracted code. If s, declare them in the target method as temporary variables.
• Look to see whether any of these local-scope variables are modified by the extracted code. If one variable is modified, see whether you can treat the extracted code as a query and assign the result to the variable concerned. if this is awkward, or if there is more than one such variable, you can't extract the method as it stands. You may need to use Split Temporary Variable  and try again. You can eliminate temporary variables with Replace Temp with Query.
• Pass into the target method as parameters local-scope variables that are read from the extracted code.
• Compile when you have dealt with all the call-scoped variables
• Replace the extracted code in the source method with a  call to the target method.
• Compile and test.

Example using Resharper:

      Here is the initial code with we are going to refactor. Things to notice here  PrintOwing function, has some comments to understand what is the purpose of following portion of code. This is Comments Code Smell. These are the places we can apply Extract Method.

Initial code:

---

• Example for extracting method without any arguments:

     Using ReSharper Extract Method we can easily move the code in method so that we do not require to comment the code but the important thing is to give proper name of the extracted method so that we do not need to go inside the method to understand the reason of the code. The shortcut for Extract Method in Resharper is Ctrl+Alt + M or (Ctrl R, M)

---

It will ask to give name of the method. As the method is printing banner so the name of the method could be as

---

• Extracting Method for Local Variable

         ReSharper is intelligent enough to understand the local variable used inside code. So it will automatically take local variable as parameter to the extracted method. Here as example, outstanding variable is used for print detail . We can use same Extract Method refactoring from Resharper without any modification.

The outstanding variable is passed as argument inside PrintDetails method automatically.

---

• Extract Method and Reassigning a local variable

This refactoring needs to organize the code little so that it can declare local variable inside method and pass the result as return value. outstanding value is generated inside calculate outstanding portion of code. First task will be to take outstanding variable close to calculation.

---

As the outstanding variable is moved just before calculation. So doing extract method on calculation section Resharper will automatically return the result of the calculation and reassign to a local variable.

---

• Final Code after Refactoring

    The code which need to be commented, are moved to methods using Extract Method. This replace long method code into small methods sequence. As because the extracted method names are self explanatory so we do not need to go inside each code to understand what is the purpose of the method.

Output this refactoring changed PrintOwing method into three line of code which do same operation and code need less effort to understand what this PrintOwing is doing.

Code Smells : Long Parameter List refactoring by Replacing Parameter with Method using Resharper

Long list of parameters in a method, though common in procedural code are difficult to understand and likely to be volatile.

Example

public void paintComponent( Graphics gr, Component renderer, Container parent, int x, int y, int width, int height, Boolean shouldValidate)

Cause:

You might be trying to minimize coupling between objects. Instead of the called object being aware of relationship between classes, you let the caller locate everything; then the method concentrates on what is being asked to do with  the pieces.

Or a programmer generalizes the routine to deal with multiple variations by creating a general algorithm and a lot of control parameters

Refactoring:

There have couple of refactoring ways to reduce long parameter

• Replace Parameter with method
• Introduce Parameter Object
• Preserve  Whole Object

1. Replace Parameter with method

use replace parameter with method when you can get the data in one parameter by making  a request of an object you already know about. This object might be a field or it might be another parameter.

Mechanics

• If necessary, extract the calculation of the parameter into a method
• Replace references to the parameter in method bodies with references to the method
• Compile and test after each replacement
• Use Remove Parameter on the parameters

Following code is an example where we can replace the parameter using method. The discount level can be called inside discountPrice method. It does not need to pass as parameter.

---

Now I will refactor the above code using Resharper. To begin we can extract a method for calculation of discount level.

In visual studio select the line you want to extract as method using Resharper. After that you can right click as image or can use Control+R, M

---

Give proper name of the method

---

After extracting method, code looks like

---

Now Inline the method inside as parameter using Resharper

---

The code state

---

Again do inline for discountPrice parameter

---

The next window you can select discountLevel

---

The code will change will be as

---

You can also  move the Temporary variable basePrice using Extract Method and  Inline refactoring technique.

The final state of code looks like

Resharper is very good tool you can use for refactoring without the fear of breaking code. But it is recommended to compile your code after each refactoring.

This code look much better and organized after removing unnecessary parameters.

In the next article I will continue other refactoring techniques to reduce Long parameter list.

Why Refactoring is Important Part of Design and Introduction to Code Smells

 

Up Front Design

In our current understanding of software development we believe that we design and then we code. A good design comes first, and then the code comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.

 

How about Agile development, Evolutionary Design?

Agile suggests evolutionary design that allows evolution to become  a viable strategy. It also provides new challenges and skills as designers need to learn how to do a simple design, how to use refactoring to keep design clean, and how to use patterns in an evolutionary style. - Martin Fowler.

 

Why  is Refactoring important in Agile?

With refactoring you find the balance of work changes. You find that design, rather than occurring all up font, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as  development continues. Refactoring is part of evolutionary design.

 

Does Refactoring violate YAGNI?

The point of YAGNI is that you don't add complexity that isn't needed for the current stories. That is part of the practice of simple design. Refactoring is needed to keep the design as simple as you can, so you should refactor whenever you realize you can make things simpler.

 

So Is Design Dead?

Not by any means, but the nature of design has changed. In Agile design looks for the following skills

• A constant desire to keep code as clear and simple as possible.
• Refactoring skills so you can confidently make improvements whenever you see the need.
• A good knowledge of patterns: not just the solutions but also appreciating when to use then and how to evolve into them.
• Designing with an eye to future changes., knowing that decisions takes now will have to be changed in the future.
• Knowing how to communicate the design to the people who need to understand it, using cod, diagrams and above all: conversation.

That's a fearsome selection of skills, but then being  a good designer  has always been tough.

 

When should we refactor the code?

Should we allocate two weeks every couple of months to refactoring? Refactoring is something you do all the time in little bursts. You don't decide to refactor, you refactor because you want to do something else and improve the design.

The rule of three

• Refactor when you add function
• Refactor when you need to fix a bug
• Refactor as you do a code review.

 

Bad Smells In Code

By Kent Back and Martin Flower

if it stinks, change it.

- Grandma Beck, discussing child-rearing philosophy

Deciding when to start refactoring, and when to stop, is just an important to refactoring as knowing how to operate the mechanics of a refactoring.

 

Code smells can be separated into two categories.

• Code Smells Within Classes
• Code Smells Between Classes.

 

Code Smells Within Classes

Comments

There's a fine line between comments that illuminate and comments that obscure. Are the comments necessary? Do they explain "why" and not "what"? Can you refactor the code so the comments aren't required? And remember, you're writing comments for people, not machines.

Long Method

All other things being equal, a shorter method is easier to read, easier to understand, and easier to troubleshoot. Refactor long methods into smaller methods if you can.

Long Parameter List

The more parameters a method has, the more complex it is. Limit the number of parameters you need in a given method, or use an object to combine the parameters.

Duplicated code

Duplicated code is the bane of software development. Stamp out duplication whenever possible. You should always be on the lookout for more subtle cases of near-duplication, too.Don't Repeat Yourself!

Conditional Complexity

Watch out for large conditional logic blocks, particularly blocks that tend to grow larger or change significantly over time. Consider alternative object-oriented approaches such as decorator, strategy, or state.

Combinitorial Explosion

You have lots of code that does almost the same thing.. but with tiny variations in data or behavior. This can be difficult to refactor-- perhaps using generics or an interpreter?

Large Class

Large classes, like long methods, are difficult to read, understand, and troubleshoot. Does the class contain too many responsibilities? Can the large class be restructured or broken into smaller classes?

Type Embedded in Name

Avoid placing types in method names; it's not only redundant, but it forces you to change the name if the type changes.

Uncommunicative Name

Does the name of the method succinctly describe what that method does? Could you read the method's name to another developer and have them explain to you what it does? If not, rename it or rewrite it.

Inconsistent Names

Pick a set of standard terminology and stick to it throughout your methods. For example, if you have Open(), you should probably have Close().

Dead Code

Ruthlessly delete code that isn't being used. That's why we have source control systems!

Speculative Generality

Write code to solve today's problems, and worry about tomorrow's problems when they actually materialize. Everyone loses in the "what if.." school of design. You (Probably) Aren't Gonna Need It.

Oddball Solution

There should only be one way of solving the same problem in your code. If you find an oddball solution, it could be a case of poorly duplicated code-- or it could be an argument for the adapter model, if you really need multiple solutions to the same problem.

Temporary Field

Watch out for objects that contain a lot of optional or unnecessary fields. If you're passing an object as a parameter to a method, make sure that you're using all of it and not cherry-picking single fields.

 

Code Smells Between Classes

Alternative Classes with Different Interfaces

If two classes are similar on the inside, but different on the outside, perhaps they can be modified to share a common interface.

Primitive Obsession

Don't use a gaggle of primitive data type variables as a poor man's substitute for a class. If your data type is sufficiently complex, write a class to represent it. 

Data Class

Avoid classes that passively store data. Classes should contain data and methods to operate on that data, too.

Data Clumps

If you always see the same data hanging around together, maybe it belongs together. Consider rolling the related data up into a larger class.

Refused Bequest

If you inherit from a class, but never use any of the inherited functionality, should you really be using inheritance?

Inappropriate Intimacy

Watch out for classes that spend too much time together, or classes that interface in inappropriate ways. Classes should know as little as possible about each other.

Indecent Exposure

Beware of classes that unnecessarily expose their internals. Aggressively refactor classes to minimize their public surface. You should have a compelling reason for every item you make public. If you don't, hide it.

Feature Envy

Methods that make extensive use of another class may belong in another class. Consider moving this method to the class it is so envious of.

Lazy Class

Classes should pull their weight. Every additional class increases the complexity of a project. If you have a class that isn't doing enough to pay for itself, can it be collapsed or combined into another class?

Message Chains

Watch out for long sequences of method calls or temporary variables to get routine data. Intermediaries are dependencies in disguise. 

Middle Man

If a class is delegating all its work, why does it exist? Cut out the middleman. Beware classes that are merely wrappers over other classes or existing functionality in the framework.

Divergent Change

If, over time, you make changes to a class that touch completely different parts of the class, it may contain too much unrelated functionality. Consider isolating the parts that changed in another class.

Shotgun Surgery

If a change in one class requires cascading changes in several related classes, consider refactoring so that the changes are limited to a single class.

Parallel Inheritance Hierarchies

Every time you make a subclass of one class, you must also make a subclass of another. Consider folding the hierarchy into a single class.

Incomplete Library Class

We need a method that's missing from the library, but we're unwilling or unable to change the library to include the method. The method ends up tacked on to some other class. If you can't modify the library, consider isolating the method.

Solution Sprawl

If it takes five classes to do anything useful, you might have solution sprawl. Consider simplifying and consolidating your design.

 

Smells to Refactoring cheat sheet http://www.industriallogic.com/wp-content/uploads/2005/09/smellstorefactorings.pdf

Source:

http://martinfowler.com/articles/designDead.html

http://www.amazon.com/exec/obidos/ASIN/0201485672/codihorr-20

http://blog.codinghorror.com/code-smells/