Pattern using in MVC

–Repository Pattern

The repository and unit of work patterns are intended to create an abstraction layer between the data access layer and the business logic layer of an application. It is a data access pattern that prompts a more loosely coupled approach to data access. We create the data access logic in a separate class, or set of classes, called a repository, with the responsibility of persisting the application’s business model.

Note —There are many ways to implement the repository and unit of work patterns. You can use repository classes with or without a unit of work class. You can implement a single repository for all entity types, or one for each type. If you implement one for each type, you can use separate classes, a generic base class and derived classes, or an abstract base class and derived classes. You can include business logic in your repository or restrict it to data access logic. You can also build an abstraction layer into your database context class by using IDbSet interfaces there instead of DbSet types for your entity sets. The approach to implementing an abstraction layer shown in this tutorial is one option for you to consider, not a recommendation for all scenarios and environments.

The database context is defined in a class variable, and the constructor expects the calling object to pass in an instance of the context:

private SchoolContext context;

 

public StudentRepository(SchoolContext context)

{

this.context = context;

}

Figure 1.1: Repository Workflow in MVC

 

Work with Data in Entity Framework

The ADO.NET Entity Framework allows developers to choose any one approach among three possible approaches: Database First, Model First and Code First.

Database First: It is a more data-centric design that is based on an existing database. The Entity Framework is able to generate a business model based on the tables and columns in a relational database. The information about our database structure (store schema), our data model (conceptual model), and the mapping among them is stored in XML in an .edmx file.

Figure 1.2: Database First Approach in Entity Framework

Model First: In this approach, we don’t have an existing database and the Entity Framework offers a designer that can create a conceptual data model. It also uses an .edmx file to store the model and mapping information. When the model has been created then the Entity Framework designer can generate the database schema that can be used to create the database.

Figure 1.3: Model First Approach in Entity Framework

Code First: Whether you have an existing database or not, you can code your own classes and properties that correspond to tables and columns and use them with Entity Framework without an .edmx file. In this approach Entity Framework does not leverage any kind of configuration file (.edmx file) to store the database schema, because the mapping API uses these conventions to generate the database schema dynamically at runtime.

Figure 1.4: Code First Approach in Entity Framework

Currently, the Entity Framework Code First approach does not support mapping to Stored Procedures. The ExecuteSqlCommand() and SqlQuery() methods can be used to execute Stored Procedures.

In this article we use the Code First approach of Entity Framework to develop a data access layer in an MVC application. The driving force behind the Code First approach is the ability to use POCO (Plain Old CLR Objects) classes. Code First uses a set of conventions to map POCO classes but that can be changed using code first data annotation:

• Primary Key is based on property name Id or ClassNameId. In other words, suppose we have a Book entity that has property Id or BookId that will be the primary key in the generated Books table.
• Table names are defined using the pluralized form of the entity class name. In other words, suppose we have an entity Book and that entity would generate a table in the database, that table name will be Books.
• The column names of the table are derived from the property names of the entity. Column names can be changed using Code First data annotation.
• The default connection string matches the name of the DataContext class.

Partial view—

Partial view is like a regular view with a file extension .cshtml. We can use partial views in a situation where we need a header, footer reused for an MVC web application. We can say that it’s like a user control concept in ASP.NET. Html.Partial returns a string, Html.RenderPartial calls Write internally, and returns void.

A partial view enables you to define a view that will be rendered inside a parent view. Partial views are implemented as ASP.NET user controls (.ascx).

Inversion of Control pattern

The Inversion of Control pattern can be implemented in several ways. The Dependency Injection pattern and the Service Locator pattern are specialized versions of this pattern that delineate different implementations. This Figure illustrates the conceptual view of both patterns.

Service Locator. The Service Locator pattern is a specialization of the Inversion of Control pattern. The Service Locator pattern introduces a locator object that objects use to resolve dependencies.

Dependency Injection (DI) is software design patterns that allow us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.

The Dependency Injection pattern uses a builder object to initialize objects and provide the required dependencies to the object means it allows you to “inject” a dependency from outside the class.

For example, suppose your Client class needs to use a Service class component, then the best you can do is to make your Client class aware of an IService interface rather than a Service class. In this way, you can change the implementation of the Service class at any time (and for how many times you want) without breaking the host code.

Use a Builder object to obtain valid instances of your object’s dependencies and pass them to your object during the object’s creation and/or initialization.

Key points about DI

1. Reduces class coupling
2. Increases code reusing
3. Improves code maintainability
4. Improves application testing