Visual Studio Generate Class From JSON or XML

Introduction 

Below Article is on, one of the cool feature available in visual studio which helps/save effort of developer to generate class structure from json/xml string.

There is cases application written using .Net Framework written by developer received json/xml string from the web service or from the other 3rd party application it calling. After receiving xml/json string data there is need of further processing received data, which requires to deserialize received xml/json in .Net object. And for that .Net class structure need to be created which match with json/xml string data so that json/xml string deserialize correctly.

Problem Statement

For example:

Program receives following json string by calling webservice or 3rd party program.

JSON

{"employees":[
    {"firstName":"John", "lastName":"Doe"},
    {"firstName":"Anna", "lastName":"Smith"},
    {"firstName":"Peter", "lastName":"Jones"}
]}

XML

  <employees>
    <employee>
        <firstName>John</firstName> <lastName>Doe</lastName>
    </employee>
    <employee>
        <firstName>Anna</firstName> <lastName>Smith</lastName>
    </employee>
    <employee>
        <firstName>Peter</firstName> <lastName>Jones</lastName>
    </employee>
</employees>

And now there is need for deserializing received json/xml string to .Net object, so further process will be done based on received data or on received data.

Approach 1: Do it manually

In this approach developer need to have knowledge of json/xml so that he/she can understand received json/xml string and it structure. Once getting detail of xml/json and received xml/json string, developer has to convert json/xml string into meaningful class structure so desterilization done without any issue/error.

So problem with this approach is lot of work need to be done by developer like

1. Require knowledge of json/xml
2. Understand jso/xmln string sent by exteranl program
3. create class strucutre for json/xml structure, which is trial and error approch because most of the time created structure doesn't work in first go
4. If json/xml string having complex structure than its difficult as well as require time to create class structure to deserialize json/xml string

Approach 2 : Automated using Visual Studio

In this approach make use of Visual studio to generate class just by copy pasting xml/json string.

Following steps need to be done for generating class

1. Copy json/xml string
   
   JSON
   
   
   
   
   XML
   
   
   
   
   
2. Go to Edit>Past Sepcial > Paste JSON As Classes or Paste XML As Classes
   
   
   
   
   
   
3. Visual studio generate Class structure for developer as below
   
   Below is example of class structure created by copy and pasting JSON string
   
   

       public class EmployeeList
       {
           public Employee[] employees { get; set; }
       }
   
       public class Employee
       {
           public string firstName { get; set; }
           public string lastName { get; set; }
       }
   
   

   
   Below is example of class structure created by copy and pasting XML string
   
   

   /// 
       [System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
       [System.Xml.Serialization.XmlRootAttribute(Namespace = "", IsNullable = false)]
       public partial class employees
       {
   
           private employeesEmployee[] employeeField;
   
           /// 
           [System.Xml.Serialization.XmlElementAttribute("employee")]
           public employeesEmployee[] employee
           {
               get
               {
                   return this.employeeField;
               }
               set
               {
                   this.employeeField = value;
               }
           }
       }
   
       /// 
       [System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
       public partial class employeesEmployee
       {
   
           private string firstNameField;
   
           private string lastNameField;
   
           /// 
           public string firstName
           {
               get
               {
                   return this.firstNameField;
               }
               set
               {
                   this.firstNameField = value;
               }
           }
   
           /// 
           public string lastName
           {
               get
               {
                   return this.lastNameField;
               }
               set
               {
                   this.lastNameField = value;
               }
           }
       }
   

   
   
   
   

As you see in above code it will generate correct attribute for xml on class so deserialization done without any issue/error.

Advantage of this solution

1. No need to understand xml/json
2. No effort require for creating class

Summary

Visual studio feature of creating class based on string really helpful to developer because understanding json/xml string and creating class structure requires efforts and sometime very frustrating.

SOLID Principle In Detail

SOLID principles are the set of principle fist given by Robert.C.Martin. SOLID principle as name given its set of principle that allows building SOLID software system (i.e. Application, Application Module), if one implement software according to this set of principle.

SOLID software system means its allows to build system that is

• Easy to maintain
• Easy to extend
• Easy to understand
• Easy to implement
• Easy to explain

SOLID principles are related with the design and maintenance of software system. Most of the developer mix SOLID principles with OOD principles and Design patterns. Below image that removes confusion of OOD principles and Design patterns

Note: This is my interpretation of the arranging thigs.

So as per image

1. OOD Principle (Abstraction, Encapsulation, Inheritance, Polymorphism)
2. SOLID principle
3. Software Design Patterns (GOF patterns, Dependency injection & patterns)
4. Martin Flower’s Enterprise Application Architectures Pattern (additional but required)
5. Domain Driven Design Architecture (additional but required)

S.O.L.I.D is acronym for

1. Single Responsibility Principle
   
   Principle is related to Designing software module, class or function that should perform only one task. So this principle is about Creation.
   
   
   
   
   In Detail Read : Single Responsibility Principle In Detail
   
   
2. Open/Close Principle
   
   Principle is applied after 1 (Single Responsibility Principle), again this principle is related to Designing module, class or function. But it about closing already designed thing for modification but opening designed thing for extension i.e. extending functionality. So this principle is about extension.
   
   
   
   
   In Detail Read : Open Closed Principle
   
3. Liskov Substitution Principle
   
   Principle is related to substitution of child in place of its parent. So principle is about relationship i.e. inheritance.
   
   
   
   
   In Detail Read : Liskov Substitution Principle
   
4. Interface Segregation Principle
   
   Principle is related to designing of interfaces as one of the basic rules of designing says depends on abstraction. Principle is about design interface such a way, so that client of interface not force to implement not required things. So principle is about efficient interface design.
   
   
   
   
   
   In Detail Read : Interface Segregation Principle


5. Dependency Inversion Principle
   
   Principle is related to designing decoupling modules, classes of software system. This principle mostly applied after 4 (Interface Segregation principle) because interface are one form of abstraction and this principle is related to Details (module/class) should depend on abstraction, and abstraction should not depend on detail. So this principle is about creating loosely coupled system.
   
   
   
   
   In Detail Read : Dependency Inversion Principle

Dependency Inversion Principle

The Dependency Inversion Principle is one of the SOLID principles defined by Robert C. Martin. This principle is about dependencies among the components (such as two modules, two classes) of the software.

The principle says that high-level modules should depend on abstraction, not on the details, of low level modules, in other words not the implementation of the low level module. Abstraction should not depend on details. Details should depend on abstraction. In simple words the principle says that there should not be a tight coupling among components (in other words two modules, two classes) of software and to avoid that, the components should depend on abstraction, in other words a contract (interface or abstract class).

Dependency Inversion Principle in Real life

To understand the second problem better way, let's see a real life scenario of a computer or laptop.

As you can see in the preceding image we have a port for each external device to which I can associate an external device and do our work.

But the problem with this is, I cannot attach my keyboard to a printer port and vice versa. The same problem occurs with the other devices. So this is like a tight coupling, that I cannot change my external device on the given interface, in other words on which I depend.

Solution to this is USB port.

If I have a USB port then I can easily attach any device to my machine and perform my task.

Example of Dependency Inversion Principle in Application Development

The following is a class diagram of tight coupling that does not follow the principle.

Public Class Customer  
{  
    CustomerRepository CustomerRepository;  
    Public Customer  
    {  
        CustomerRepository = new CustomerRpository();  
}  
  
Public bool Save()  
{  
    CustomerRepository.Save();  
}  
}  
  
Public class CustomerRepository  
{  
    Public bool Save(dattype data)  
{  
              //Sql Connection object and Save data in Sql server   
}  
}  

The preceding code is tightly coupled because the current repository deals with the SQL server. So if the requirement is to use an Oracle server then there is modification required for the Customer class.

So to avoid that, make the customer class depend on abstraction. The following is an image of a class diagram where the customer depends on abstraction and supports both SQL and Oracle servers.

Public Class Customer   
{  
    CustomerRepository CustomerRepository;  
    Public Customer   
    {  
        CustomerRepository = new CustomerRpository();  
    }  
  
    Public bool Save()   
    {  
        CustomerRepository.Save();  
    }  
}  
  
Public class CustomerRepository   
{  
    Public bool Save(dattype data)   
    {  
        //Sql Connection object and Save data in Sql server     
    }  
} 

So in the preceding code the customer class depends on ICustomerRepository abstraction, in other words an interface. Another thing is here the customer class receives a dependency via consumption of the customer class or using a dependency container.

Note: Here is an example of the class but the same goes for the modules designed in software because dependency inversion is about providing a set of abstraction policies on which the details depend and the policy that provides flexibility in the software system.

Disadvantages

Application modules become tightly coupled, that means:

1. The testability of the module becomes difficult.
2. Parallel development of the module becomes difficult.
3. Many changes are required when there is modification in the module and when there are changes in the module it depends on. 

Read more Dependency Injection talks about the disadvantages and advantages of using dependency inversion.

Note: Dependency Injection is not the same as Dependency Inversion because Dependency Inversion is about defining an abstraction policy for the software module whereas Dependency Injection is a set of patterns to supply dependency.

Interface Segregation Principle

The Interface Segregation Principle is one of the SOLID principles defined by Robert C. Martin. It is one of the rules of software development that says to always code according to a contract, in other words an interface, not against the implementation, in other words a concrete class, because coding against an interface provides advantages like flexibility, loose coupling, testable code and so on. This principle is related to creating an interface for implementation.

The principle says “Client (class implementation interface) should not force to implement Interface that they don't use.” In simple words the principle is saying, do not design a big fat interface that forces the client to implement a method that is not required by it, instead design a small interface. So by doing this class only implement the required set of interface(s).

If there is big fat interface then break it into a set of small interfaces with the related method(s) in it. It's similar to normalizing our database like normalizing database from 1NF to 3NF where a big table is broken into tables with related columns.

Interface Segregation Principle in Real life

In terms of the violation of the ISP, the following image shows a big dustbin for throwing all kinds of garbage away without any kind of segregation.



With ISP, the following image is a good example of segregation in our real life.

That is an image of a waste bin segregation that shows which one to use for throwing away trash we use.

Example of ISP in Application Development

Here is an example of a banking customer for a bank with the following types of customers:

1. Corporate customer: For corporate people.
2. Retail customer: For individual, daily banking.
3. Potential customer: They are just a bank customer that does not yet hold a product of the bank and it is just a record that is different from corporate and retail.

The developer of a system defines an interface for a customer as in the following that doesn't follow the ISP rule.

It looks OK at first glance but it's a big fat interface for the customer with problem since it forces the client class to implement methods that are not required.

1.  A potential customer as described taht does not hold any product is forced to implement a product property. 
2. A potential customer and a retail customer both are forced to have a Customer Structure property but in a real scenario a Corporate customer has a Customer Structure that describes a customer hierarchy. 
3. A potential customer and a retail customer both are forced to implement a BusinessType but that just belongs to a corporate customer. 
4. A corporate customer and a potential customer are forced to implement an Occupation property that is just a blog to a retail customer. 

A solution to the preceding problem is to split the fat interface into meaningfull parts, in other words small interfaces, so the customer type only implements the interface that is required by it.

The following is an image that follows the ISP:

Disadvantages

1.  Deliver big fat interface that forces the client to implement a method that is not required.
2. The client ends up implementing a usefuless method, in other words a method that has no meaning to the client. This decreases the readability of the code and also confuses the developer using the client code.
3. The client interface ends up violating SRP sometime since it might perform some action that is not related to it.

Liskov Substitution Principle

Liskov Substitution Principle – is one of the SOLID principles defined by Barbara Liskov. Principle is based on the parent-child relationship in other words inheritance features of OOD (Object Oriented Design). Principle says “When class S is a subtype of class T then an object of type T can be replaced by an object of type S without affecting functionality/correctness of the implementation or program”.

In simple words it says “Places in implementation (Class/Function) that use a base class, in other words consume a service of a base class, must work correctly when the base class object is replaced by a child class (derived class) object.”

Liskov Substitution Principle in Real life 

The following is an example of an electric bulb that actually violates substitution. When the bulb fails it is replaced with a new bulb. Here in this example the old bulb is replaced with the new bulb.

Perfect Substitution

Note:
Here in this example in the family of bulbs, considering the old bulb to be a parent of all bulb types and a CFG bulb is a child of the same family inherited from it.

When one replaces a failed bulb, in other words in programming terms substitutes the old with the new, it must provide light that is provided by the old bulb, in other words works without affecting correctness or functionality (provides a constant light in the house). In the preceding example the substitution worked perfectly since there is no modification in functionality.

Violation Example

The preceding image shows the violation of the principle. Since replacing with a decoration bulb (that provides light in the form of decoration) instead of a bulb meant for just providing light in the house. That actually is a violation in the sense of modifying the functionality because a decoration bulb does not provide the same functionality for the consumer.

Example of not following Principle in Application Development

Continuing with bank savings account that is already explained in previous articles about the Open-Closed Principle.

 
Interface ISavingAccount   
{   
   //Other method and property and code   
   bool Withdrwal(decimal amount);   
}   
   
Public Class RegularSavingAccount : ISavingAccount   
{   
  //Other method and property and code related to Regular Saving account   
   
   Public bool Withdrwal ()   
  {   
    Decimal moneyAfterWithdrawal = Balance-amount;   
if(moneyAfterWithdrawal >= 1000)   
{   
    //update balace    
    return true;   
}   
else   
  return false;   
  }   
}   
   
Public Class SalarySavingAccount : ISavingAccount   
{   
  //Other method and property and code related to Salary Saving account`   
   Public bool Withdrwal ()   
  {   
    Decimal moneyAfterWithdrawal = Balance-amount;   
    if(moneyAfterWithdrawal >= 0)   
    {   
       //update balace    
       return true;   
    }   
    else   
      return false;   
  }   
}   
Public Class FixDepositSavingAccount : ISavingAccount   
{   
  //Other method and property and code related to Salary Saving account`   
   Public bool Withdrwal ()   
  {   
    Throw New Excpetion(“Not supported by this account type”);   
  }   
}   

In the preceding code the IsavingAccount interface is implemented by a different kind of savings account of the bank, like Regular, Salary and FixDeposit savings account.

But as per the banking rules, a FixDeposit savings account doesn't provide a withdrawal facility whereas another bank account might provide a withdrawal facility.

So the developer might write code to raise an exception when an attempt is made to withdraw from a FixDeposit savings account.

Now consider the following method in a class calling a withdrawal by casting the actual object to the parent class type.

Public class AccountManager   
{   
    Public bool WithdrawFromAccount(IsavingAccount account)   
    {   
         account.Withdraw(amount);   
    }   
}   

The following code calls the method,

//works ok  
AccountManager.WidhdrawFromAccount(new RegularSavingAccount());  
//works ok  
AccountManager.WidhdrawFromAccount(new SalarySavingAccount());  
//throws exception as withdrawal is not supported  
AccountManager.WidhdrawFromAccount(new FixDepositSavingAccount()); 

Violation of Liskov Substitution Rule

So the preceding code breaks the Liskov Substitution rule since the inherited FixDepositSavingAccount class is modifying the functionality of the withdrawal. Because the savings account should provide functionality to withdraw an amount without throwing any error.

How to stop violating the rule

To stop violating the rule one must verify the inheritance tree, in other words child classes inherited from the parent class should not break the functionality when the child class object replaces the parent class object.

So the class must inherit from the proper parent class in such a way that when the child class replaces the parent, it doesn't break the actual functionality provided by the parent class.

Note
It's not always true that one must make changes in the inheritance tree but making changes at the class and method level also resolves problems. To get such kind of example click on the link: Object Menter (Square and rectangle example).

In the preceding image the new classes WithWithdrawal and WithoutWithdrawal are created and the child classes are inherited from the respective parent class.

So in the preceding code:

Interface ISavingAccount   
{}   
Public Class SavingAccountWithWithdrawal : ISavingAccount   
{   
    Public virtual bool Withdrwal () {}   
}   
Public Class SavingAccountWithoutWithdrawal : ISavingAccount   
{   
}   
Public Class RegularSavingAccount : SavingAccountWithWithdrawal   
{    
  Public bool Withdrwal ()   
  { //implementation   
  }   
}   
Public Class SalarySavingAccount : SavingAccountWithWithdrawal   
{    
  Public bool Withdrwal ()   
  {//implementation   
  }   
}   
Public Class FixDepositSavingAccount : SavingAccountWithoutWithdrawal   
{   
}   

Now using it:

Public class AccountManager   
{   
    Public bool WithdrawFromAccount(SavingAccountWithWithdrawal account)   
    {   
       account.Withdraw(amount);   
    }   
}   

Now the following code to call method:

//works ok  
AccountManager.WidhdrawFromAccount(new RegularSavingAccount());  
//works ok  
AccountManager.WidhdrawFromAccount(new SalarySavingAccount());  
//compiler gives error   
AccountManager.WidhdrawFromAccount(new FixDepositSavingAccount());  

Disadvantage of not following the Liskov Substitution Principle

• Developed code throws a run time error or exception or also might not work as expected and that leads to program failure or incorrect results.
• The preceding discussion shows an example of throwing an exeption by a child class for a not supported method.
• Read link: Object Mentor that shows an example (square and rectangle example) of giving incorrect results when not following the principle.

So the biggest advantage of not following this rule is: it causes problems at runtime rather than causes application failure or incorrect results.

Open Closed Principle

The Open Closed Principle is one of the SOLID principles defined by Robert C. Martin. The principle says “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”.

So in simple words it says that an implementation (of a class or function), once created, should be closed for further modification, in other words one should not modify an implementation (of a class or function) of logic and/or functionality. One can do refactoring or resolve errors of implementation (of a class or function) but the implementation (of a class or function) is open for extension, in other words one can extend the implementation (of a class or function) of logic and/or functionality.

Real Life Example of Open Closed Principle

An electric adapter is a good example of this principle.

As you can see in the image:

1. An adapter in the wall is always closed for modification, in other words we cannot change it once it is fitted or extended if we want more.
2. But an adapter always provides a method of extension, so we can plug in an extension board of an adapter for more adaptation.
3. So you plug in an extension board and extend an existing electric adapter fitted in wall.

Example of not following the principle in Application Development

A bank offers various types of the savings accounts (Salary Saving, Regular Saving and so on) that meet the needs of many types of customers. A bank has differing sets of rules and each savings account type has a different set of rules to calculate interest.

To calculate the interest of an account, developers have developed the following class with methods to calculate interest.

Public class SavingAccount   
{   
    //Other method and property and code   
    Public decimal CalculateInterest(AccountType accountType)   
    {   
        If(AccountType==”Regular”)   
        {   
            //Calculate interest for regular saving account based on rules and    
            // regulation of bank   
            Interest = balance * 0.4;   
            If(balance < 1000) interest -= balance * 0.2;   
            If(balance < 50000) interest += amount * 0.4;   
        }   
        else if(AccountType==”Salary”)   
        {   
            //Calculate interest for saving account based on rules and regulation of    
            //bank   
            Interest = balance * 0.5;   
        }   
    }   
}  

So in the preceding code the SavingAccount class's CalculateInterest method does a calcualtion based on the account type like Salary and Regular.

So the implementation is not following the Open Closed principle because if tomorrow the bank introduces a new SavingAccount type then there is a requirement to modify this method for adding a new case for the new account type. An example is if the bank introduces a “Child Savings Account type” requiring a new condition for calculating the interest for this account type. That means that the method is always open for modification.

One more thing to note here is that the method is also not following the Single Responsibility Principle. Since here the method is doing more than one thing, like calculating interest for more than one type.

How to Implement the Open Closed Principle

Inheritance is only one way to implement the Open Closed Principle. Because inheritance is only an Object Oriented Design (OOD) basic pillar that allows extension of functionality of an existing class.

To implement the Open Closed Principle one can use interface, an abstract class, abstract methods and virtual methods than inherit them when you want to extend functionality.

So the preceding problem of a Savings Account can be resolved as in the following.

 
Interface ISavingAccount   
{   
   //Other method and property and code   
   decimal CalculateInterest();   
}   
Public Class RegularSavingAccount : ISavingAccount   
{   
  //Other method and property and code related to Regular Saving account   
  Public decimal CalculateInterest()   
  {   
    //Calculate interest for regular saving account based on rules and    
    // regulation of bank   
    Interest = balance * 0.4;   
    If(balance < 1000) interest -= balance * 0.2;   
    If(balance < 50000) interest += amount * 0.4;   
  }   
}   
   
Public Class SalarySavingAccount : ISavingAccount   
{   
  //Other method and property and code related to Salary Saving account`   
  Public decimal CalculateInterest()   
  {   
    //Calculate interest for saving account based on rules and regulation of    
    //bank   
    Interest = balance * 0.5;   
  }   
}  

In the preceding code two new classes are created, RgularSavingAccount and SalarySavingAccount, that is inherited from IsavingAccount.

So if there is a new account added by the bank than there is no need to modify the logic of exiting classes, just extend the functionality by inheriting an interface.

Finally the preceding example implements the Open Closed Principle since there is no need to modify the existing implemented logic and it allows extension for adding new logic.

And the preceding example also implements the Single Responsibility Principle since each class or function is doing only one task.

Note : An interface is created here just as an example. There could be an abstract class of SavingAccount that is implemented by a new savings account type.

Read: Decorate design pattern that also helps to understand.

Disadvantage of not following Open Closed Principle

1. Since a class or function always allows the addition of new logic, whenever new logic is added it is always necessary to test for full functionality. That requires the addition of a new test case for the added functionality and might also require the modification of an existing test case that fails because of added functionality.
2. It also breaks the Single Responsibility Principle since a class or function might end up doing multiple tasks.
3. Class or function maintenance becomes difficult since a class or function can become thousands of lines of code that is difficult to understand.

How to Identify not following Single Responsibility Principle

A class or function is always open for modification, in other words always allows adding more logic to it. Like in the preceding example.