Friday, February 28, 2014

Enum Support in MVC 5.1

 

Enum support for MVC views is a new feature introduced in Asp.net MVC 5.1. If you have Enum in your model view will create a dropdown list or radio button list in the view for you.

See the example below.

Model
  1. public class MyData
  2.     {
  3.         public int Id { get; set; }
  4.  
  5.         public MyEnum Enum1 { get; set; }
  6.  
  7.         public MyEnum? Enum2 { get; set; }
  8.  
  9.         public FlagsEnum FlagsEnum { get; set; }
  10.     }

 

Enum as Dropdown List

 

  1. <div class="form-group">
  2.          @Html.LabelFor(model => model.Enum1, new { @class = "control-label col-md-2" })
  3.          <div class="col-md-10">
  4.              @Html.EditorFor(model => model.Enum1)
  5.              @Html.ValidationMessageFor(model => model.Enum1)
  6.          </div>
  7.      </div>
  8.  
  9.      <div class="form-group">
  10.          @Html.LabelFor(model => model.Enum2, new { @class = "control-label col-md-2" })
  11.          <div class="col-md-10">
  12.              @Html.EditorFor(model => model.Enum2)
  13.              @Html.ValidationMessageFor(model => model.Enum2)
  14.          </div>
  15.      </div>

Following shows the how view renders. As you can see as Enum2 member is nullable it does not have any value selected by default.

image

Enum as Radio button List

 

  1. <div class="form-group">
  2.           @Html.LabelFor(model => model.Enum1, new { @class = "control-label col-md-2" })
  3.           <div class="col-md-10">
  4.               @Html.EditorFor(model => model.Enum1, templateName: "Enum-radio")
  5.               @Html.ValidationMessageFor(model => model.Enum1)
  6.           </div>
  7.       </div>
  8.  
  9.       <div class="form-group">
  10.           @Html.LabelFor(model => model.Enum2, new { @class = "control-label col-md-2" })
  11.           <div class="col-md-10">
  12.               @Html.EditorFor(model => model.Enum2, templateName: "Enum-radio")
  13.               @Html.ValidationMessageFor(model => model.Enum2)
  14.           </div>
  15.       </div>
 

image

Happy Coding !!!!!!!!!!

Thursday, February 27, 2014

TestCase Attribute (NUnit 2.5)


Have you ever thought how easy would it be if we could pass parameters and expected result to a Unit Test method we have rather writing multiple test methods.
It is possible now with NUnit 2.5 “TestCase” Attribute.

Suppose you have a method to test whether a year is a leap year or not which you want to test by passing different values here is the solution.
 
        [TestCase(2000, Result = true)]
        [TestCase(1996, Result = true)]
        [TestCase(2013, Result = false)]
        public bool IsLeapYearTest(int year)
        {
            return DateTime.IsLeapYear(year);
        }
and if you want to pass multiple parameters just add them comma seperated as below example.
   
        [TestCase(12, 3, Result = 4)]
        [TestCase(12, 2, Result = 6)]
        [TestCase(12, 4, Result = 3)]
        public int DivideTest(int n, int d)
        {
            return (n / d);
        }

This helps us to provide test methods with parameters as well as providing inline date to be used when invoking that method.

Happy Coding

Sunday, February 9, 2014

February 2014

 

Please find the presentation & the sample code for February Sri Lanka .net Forum meet up which I did on c# interfaces here.

https://skydrive.live.com/redir?resid=80EDE0125C9CA03A!109&authkey=!AJKHEV7BrDCEP1c&ithint=file%2c.zip

Friday, February 7, 2014

SOLID Design Principles

 

SOLID design principles are some set of best practices for object oriented programming. SOLID stands for

  • Single responsibility principle (SRP)
  • Open-Closed principle (OCP)
  • Liskov substitution principle (LSP)
  • Interface segregation principle (ISP)
  • Dependency inversion principle (DIP)

 

Single responsibility principle

“There should never be more than one reason for a class to change”.

This means every object should have single focus of responsibility. This can be applied in different levels.

  1. A method should carry out one thing only
  2. A domain object should only represent one isolated object within business domain
  3. Presentation layer should be only responsible for presenting data

Purpose of implementing this principle is to get High Cohesive & Low Couples code which is easily testable and maintainable.

  • Cohesion: how strongly related and focused the various responsibilities of a module are
  • Coupling: the degree to which each program module relies on each one of the other modules

 

Open-Closed principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”

Software that works should when possible not be changed when your application is extended with new functionality.Instead it should be possible to extend the existing software with new functionality without any modification to the current codebase and without adding duplicate code or duplicate functionality.

To state the open closes principle very straightforward way you can say :

  • You should design modules that never change.
  • When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works.

 

Liskov substitution principle

“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”.

you can find good code example here.

Interface segregation principle

“Clients should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module”.

ex:-

image

 image

I here rather having all the methods for the inside in one Interface we have divide the read operation in to one single interface. So any class need only reading operation can implement. So it does not need to implement methods which are not relevant it’s need.

Dependency inversion principle

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

The goal of the dependency inversion principle is to decouple application glue code from application logic. Reusing low-level components (application logic) becomes easier and maintainability is increased. This is facilitated by the separation of high-level components and low-level components into separate packages/libraries, where interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's package. The implementation of the high-level component's interface by the low level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship. Various patterns such as Plugin, Service Locator, or Dependency Injection are then employed to facilitate the run-time provisioning of the chosen low-level component implementation to the high-level component.

you can find good document here.

 

Happy Coding !!!!