Function breakpoints in Visual Studio

Previously we discussed the concept of Hit Count breakpoints and Conditional breakpoints.  We will now discuss the concept of Function breakpoints. This functionality allows us to set the name of any function as the condition for the breakpoint to hit.

Let’s start by creating 2 different functions SetString() and GetString() and call them as SetString() first and then GetString(). 

Function Breakpoints in Visual Studio

To set the breakpoints for this type, go to Debug -> Windows -> Breakpoints to open the Breakpoints window. Select the option New -> Break at Function option from the window.

Function Breakpoints in Visual Studio

This open ups a new window and we specify the name of the GetString() function as the function condition for the breakpoint to be hit.

Function Breakpoints in Visual Studio

Hover the breakpoint and we can see its details.

Function Breakpoints in Visual Studio

Run the application and breakpoint will get hit only when the execution of the Getstring() function starts.

Function Breakpoints in Visual Studio

Easy and helpful, isn’t it. Happy coding…!!!

Posted in Tips & Tricks | Leave a comment

Hit count breakpoints in Visual Studio

Previously in our discussion, we discussed about the concept of Conditional breakpoints. In this article, we will discuss about the Hit Condition breakpoints.

Consider a case where you have a for loop with iteration of thousands of records. You know that your records at around 500th location is corrupted and you need to debug that value. Will you sit and keep pressing F5 until the record number 500 is reached ? This is where you can use the concept of Hit Condition breakpoints. This is achieved by setting Hit Count condition on the breakpoint i.e. hit the breakpoint when it has iterated 499 times.

Let’s create  a sample application to understand this. Add a for loop with iteration of 1000 records and add a condition to hit the breakpoint when the 500th record is being iterated.

To add the condition, right click on the breakpoint and select the ‘Hit Count’ condition. This will open up a window where we can define a condition to hit the breakpoint only when it meets the criteria set for its execution.

Conditional breakpoints

Here we have 4 different conditions and these. So we select the condition ‘break when the hit count is equal to‘ and set its value to be 500.

Conditional breakpoints

Hover over the breakpoint and see the details:

Conditional breakpoints

 

Run the application and see the value of variable ‘i’, when the breakpoint is hit.

Conditional breakpoints

So here when the value of i becomes 499 (starting from 0), it is iterating the 500th record and the breakpoint gets hit. So set the break point and enjoy the debugging…!!!

Posted in Tips & Tricks | Leave a comment

RESTful API using WCF Services

In this article, we will discuss about the concept how we can use WCF services to create a REST based service. We will not go into the details about what is REST architecture style. As per it’s type, our service will be of nature, where each method will act as a resource on the internet. So in order to create a REST based service, we will create a new ASP.Net project and add a WCF service project into it. Let’s call it RESTService.

RESTful API using WCF service

Next, we remove any default methods. We add a sample class named POCOClass with 2 properties of Name and Id. Next we add a method in the service, which returns a list of the type POCOClass.

RESTful API using WCF service

Next, in order to make this service a RESTful type, we need to do some code changes. These include:

  1. Add WebGet attribute or WebInvoke attribute to the methods to allow them to be used with HTTP verbs like GET, PUT, POST etc.
  2. Add a Uri template to these methods, which is nothing but a url which will identify the methods as a unique resource on the internet.
  3. Change the binding to be used as webHttpBinding type.

So let’s start by adding the WebGet attribute on the method. To use these attributes, we need to add reference to System.ServiceModel.Web.

RESTful API using WCF service

Add the WebGet attribute on the implementation of the service method.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.Net;
using System.ServiceModel.Web;
using System.Runtime.Serialization.Json;
using System.IO;
using System.Web.Http;

namespace SampleApplication
{
    public class RESTService : IRESTService
    {
        [WebGet]
        List<POCOClass> IRESTService.GetListData()
        {
            var _lstPOCOClass = new List<POCOClass>();

            _lstPOCOClass.Add(new POCOClass
            {
                Id = 1,
                Name = "User 1"
            });

            _lstPOCOClass.Add(new POCOClass
            {
                Id = 2,
                Name = "User 2"
            });

            _lstPOCOClass.Add(new POCOClass
            {
                Id = 3,
                Name = "User 3"
            }); 

            return _lstPOCOClass;
        }
    }
}

Next, in order to make it as a resource on the web, we use the UriTemplate parameter to the WebGet attribute above. We also add a parameter named ResponseFormat, to make it return a JSON type.

 [WebGet(UriTemplate = "/GetListData", ResponseFormat = WebMessageFormat.Json)]
        List<POCOClass> IRESTService.GetListData()
        {
            var _lstPOCOClass = new List<POCOClass>();

            _lstPOCOClass.Add(new POCOClass
            {
                Id = 1,
                Name = "User 1"
            });

            _lstPOCOClass.Add(new POCOClass
            {
                Id = 2,
                Name = "User 2"
            });

            _lstPOCOClass.Add(new POCOClass
            {
                Id = 3,
                Name = "User 3"
            }); 

            return _lstPOCOClass;
        }

Now we need to add settings for making it use webHttpBinding.

First,  we need change the endpoint behavior to use the webHttpBinding. This is to be done inside

system.serviceModel => behaviors => endpointBehaviors => behavior

and change the endpoint to use the webHttpBinding. This is to be done in:

system.serviceModel => services => service => endpoint

The complete settings will look like:

<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>

      <endpointBehaviors>
        <behavior name="web">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="SampleApplication.RESTService">
        <endpoint address="" behaviorConfiguration="web" binding="webHttpBinding"
                  contract="SampleApplication.IRESTService" >
        </endpoint>
      </service>
    </services>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
  
</configuration>

That’s it. We are done with the settings and now we simply need to test it. To do this, we will browse the service to get the url.

RESTful API using WCF service

Next, we use the Google chrome extension app called Postman to test the service. Add the service url and select GET as the HTTP verb.

RESTful API using WCF serviceClick the Send button and see the results.

RESTful API using WCF service

Next, let’s try to POST some data to it. So we add another method which receives data of the type POCOClass from the HttpBody. We also add the WebInvoke attribute and the UriTemplate for it.

        [WebInvoke(UriTemplate="/PostUserData", RequestFormat=WebMessageFormat.Json)]
        void IRESTService.PostUserData([FromBody] POCOClass userData)
        {
             
        }

Now again, we use our POSTMan app to POST the data to the same url, but with method name as per defined in the uri template.

RESTful API using WCF service

Click Send and see the results. We are getting the results on the server.

RESTful API using WCF service

Easy, isn’t it. So create the REST services as per the requirements. No need to use the SOAP based WCF service, making it lighter.

Posted in WCF Services | Leave a comment

Conditional breakpoints in Visual Studio

It’s a small but very powerful tip, especially helpful when you are debugging large code base. This is the concept of Conditional Breakpoints.

As the name itself suggests, it is setting the breakpoints which are hit, only when certain condition is met. It’s easy to implement as well. Create a new application and set a normal breakpoint.

Conditional breakpoints

So this will be hit every-time the Page_Load executes. This could be very annoying when you are debugging for a bug and this keeps on hitting this breakpoint. So let’s make it conditional. Simply put your mouse on the breakpoint, right click and select ‘Condition‘.

Conditional breakpoints

This will open up a window where we can define a condition to hit the breakpoint, only when the condition is met. Even you get the intellisense help for it.

Conditional breakpoints

See how the color of the breakpoint changes with a plus sign on it. Also, hover over it and you can see the details.

Conditional breakpoints

Now let’s run the application. First time, no breakpoint is hit. Press the button for postback and see the breakpoint gets executed.

Conditional breakpoints

Even you can set this condition to be on your variables or properties etc. you define in your code. So happy debugging now…!!!

Posted in Tips & Tricks | Tagged | Leave a comment

Onion architecture with MVC using repository pattern

Finally i am up with my article related to onion architecture. The main aim of this article is try to learn the onion architecture and have a sample sample code which is loosely coupled and easily maintainable. So to learn this concept efficiently, our application would consist of following:

  • An mvc application using Onion architecture.
  • Entity framework with database first approach.
  • Dependency injection using Unity container.
  • Repository pattern with a repository per entity.

So let’s start with some of the basics.

What is Onion architecture ?

This architecture term was coined by Jeffrey Palermo back in 2008. Long time since then and it has become very popular these days. When you get into the details of this architecture, you might feel that you were already using from long time but may not be aware of that.

Just a quick introduction to it. Onion architecture is the way of designing your application layers in such a way that, like an onion, the innermost layer or the core component, we can say, is independent of the layer above it. As we move away from the core, the layers/components can depend on the layer towards the core but not on the layers above itself. For example, if we have 3 layers of architecture, and Layer1 is the innermost or the core layer, then Layer2 and then Layer3. So, to create an onion architecture based application would have Layer1 as the innermost layer, independent of Layer2 and Layer3. Then Layer2 comes above Layer1 and depends on only Layer1 and NOT Layer3. Finally, Layer3 is the outermost layer and can depend on both Layer1 and Layer2.

So the most important point in the onion architecture is that as we move from core to the top most layer, the dependency towards the inner layers increases. But there should not be any inter-dependency between the layers i.e. Layer2 should not depend on Layer3. So we should try to keep the core layer as much generic as possible, though not necessary always. In such a case, our architecture layers would look like the following:

Onion Architecture & Dependency Injection using Unity

Let’s try to understand by creating a new MVC application. We will create an application with tight coupling, and try to convert into Onion architecture with the system of loosely coupled components. Fire up your visual studio and add a new project of type MVC.

Onion Architecture & Dependency Injection using Unity

Next we will display some sample data on a page, from database. For this, we will create a sample database and use the entity framework database first approach. So let’s add an .edmx and update it from a sample database. But, adding this edmx to the same project does not makes a good sense, as the models will be tightly coupled to the UI layer. So what we will do is that we add a new project layer of type class library, with the name SampleArchitecture.Infrastructure and add the .edmx to it. See the code below:

Onion Architecture & Dependency Injection using Unity

Next, in order to display the data from the table, we create a new class called UsersRepository.cs, in the same Infrastructure project, which will have the methods for CRUD operations related to the Users table. For our example, we will add a simple method GetAllUsers, which will get all the records from the Users table. See the code below:

Onion Architecture & Dependency Injection using Unity

Now let’s add a controller, its corresponding view, and make a call to the repository GetAllUsers method. In order to access the repository, we need to add reference to the Infrastructure project. So add the reference to it and call the method as:

Onion Architecture & Dependency Injection using Unity

Now bind the Model in the View, run the application and see the results.

Architecture_5_1

Looks good so far. But there are few issues in this code.

1. Violation of Single Responsibility Principle: The controller class is dependent on the concrete UserRepository class. The issue is that the Controller method is now responsible for multiple tasks, i.e. instantiating the repository and returning the view with the data. This violates the S of the SOLID principles, which says that each class/function should be responsible or only one task.

2. Tight coupling between the Web and the Infrastructure project:  Our web project is directly dependent on the entities. This includes not only the Controller class but also the View (as the View will use the Model property to bind the data). So in future, for some reason, we need to remove the use of entity framework, it will not only affect the Infrastructure project but also the web application as we directly refer the entities into the Controller and View.

3. Concrete Repository class: UserRepository is concrete class in the project. As a result, where-ever, it will be used in the project, it will increase coupling between the components.

Onion Architecture & Dependency Injection using Unity

So let’s start by reducing the tight coupling caused by the use of the entity framework with View and Controller. So what can we do here ? We introduce plain POCO classes, which will carry the data from the data access layer, through repository, to Controller and then finally the View. But a very important thing to be decided, where to add these POCO classes. The reason being, we are trying to use the onion architecture. We can add them to the Infrastructure project. But the point is that, these classes are just required to be container classes, carry the data and bind with the UI. So why not isolate them to another independent layer. So we add another layer called SampleArchitecture.Core,  and add its reference in the Infrastructure and the web layer. This will be also in sync with the onion architecture, where

1. Core layer will be independent of the Infrastructure and Web layers. This becomes Layer1 of our earlier discussion.

2. Infrastructure layer will be independent of the Web layer, but will be dependent on the Core layer, for the POCO classes. This becomes Layer2 of our earlier discussion.

3. Web layer will be dependent on both the Core and the Infrastructure layers, for the use of POCO classes and the repository classes. This becomes Layer3 of our discussion earlier.

So let’s add a new project of type ClassLibrary and add a POCO class called UserUI. Another advantage of these classes is that we can add the validations of the model here itself.

Onion Architecture & Dependency Injection using Unity

Next, we change the repository method to use the POCO class and return the same to the Controller and bind it with the View.

Onion Architecture & Dependency Injection using Unity

Run the application and now you can see the results.

Onion Architecture & Dependency Injection using Unity

So now even if you need to remove the entity framework, just need to make changes in the Infrastructure layer. No need to change the Controller method or the View binding and hence no changes in the Core and Web layers.

Now, we will try to remove the process of creating the instance of the repository class, within the controller. For this, we will use the concept of Inversion of ControlThis means, we will invert the controllers’ responsibility of initializing the repository from the Controller, to any other locationThis will be done by one of the dependency injection container named Unity. So basically this dependency injection container will be responsible for creating the required dependency and passing it to the controller. As per MSDN, Unity is:

Unity is a general-purpose container for use in any type of Microsoft.NET Framework-based application. It provides all of the features commonly found in dependency injection mechanisms, including methods to register type mappings and object instances, resolve objects, manage object lifetimes, and inject dependent objects into the parameters of constructors and methods, and as the value of properties of objects it resolves.

In order to use it, we need to add reference to the unity dll’s using the nuget package manager. This is to be added in the Web project, as we need to inject the dependency on the controller methods. Let’s start by adding the reference to the unity dll’s.

Onion Architecture & Dependency Injection using Unity

Next, we add an interface named IUserRepository add the definition of GetAllUsers method. Implement this interface on the UserRepository class. Again the same question, where to add the interface ? And same concept to answer this question, this is a re-usable component and should be an independent component. So we add it to the SampleArchitecture.Core project. Makes sense, doesn’t it ? So the code changes to:

Onion Architecture & Dependency Injection using Unity

Now the controller needs the instance of the UserRepository, which will be provided by the UnityContainer. As the name suggests, unity container is like a container which is responsible for providing the required dependency to a class. In our example, we need the UserRepository instance. So unity container will provide it, to us. But before it can do that, we need to register the required dependencies with the container. Registering the dependency is like telling the container that when i am using this interface, provide me an instance of the concrete class that implements this interface. At run time, get the required dependency from this container and inject to the required method using the Constructor, Property or Method injection process.

So for this, we add a class named UnityConainerRegistration and register the dependencies. We add this class in the main web project as this is where we need the dependencies to be resolved.

Onion Architecture & Dependency Injection using Unity

Next, we initialize this container in the Global.asax file. So when the application is started, it will register all the dependencies in the container.

Onion Architecture & Dependency Injection using Unity

Finally, we change our Controller to receive the dependency of UserRepository, using the Constructor, in the form of IUserRepository (as it implements this interface). This dependency gets resolved through the unity container we registered above.

Onion Architecture & Dependency Injection using Unity

So now run the application and there is no affect on the results. But in the application code, our the dependency follows what we aimed at i.e. the onion architecture. Our SampleArchitecture.Core is the innermost layer which is independent of everything. Then we have the SampleArchitecture.Infrastructure, which is dependent on the Core layer and independent of the web layer. Finally we have the web layer which is dependent on both the Core and the Infrastructure layer. This is what we aimed at:

Onion Architecture & Dependency Injection using Unity

So this is what we discussed in the starting. Wasn’t that easy to learn. Hope you enjoyed reading it. Happy coding…!!!

Posted in Design and Architecture | Tagged | Leave a comment