Why should we use design patterns?
To answer this first we need to understand what is a design pattern. A design pattern is basically nothing but a way of organizing which helps in avoiding the cluttering or mess which may lead to unwanted behaviors and erroneous results from our code. So a design pattern can be thought of as a solution to commonly faced problem, the problem that arises from the ill managed code, the problem of unexpected results and behaviors.
Thus to make your application more manageable, maintainable and avoid unexpected behaviors from our code we can implement design patterns. Implementing a design pattern is a proactive act of learning from others experience of committing common problems and being smart not to commit the them.
Design patterns in ASP.Net MVC
In MVC we already have a layered architecture then why do we need to apply further layering or design patterns? Firstly, a layer is a grouping of software components which serve for a common cause. Now a design pattern breaks down the MVC application further to make it more manageable where independent modules are less interdependent and are pluggable. By separating these sections, each can encapsulate information that can be developed and updated independently. N-tier development is an example of SoC in which the user interface (UI) is separated from both the business layer and the data access layer. Furthermore, these design patterns can proactively solve many of the common problems.
To answer this first we need to understand what is a design pattern. A design pattern is basically nothing but a way of organizing which helps in avoiding the cluttering or mess which may lead to unwanted behaviors and erroneous results from our code. So a design pattern can be thought of as a solution to commonly faced problem, the problem that arises from the ill managed code, the problem of unexpected results and behaviors.
Thus to make your application more manageable, maintainable and avoid unexpected behaviors from our code we can implement design patterns. Implementing a design pattern is a proactive act of learning from others experience of committing common problems and being smart not to commit the them.
Design patterns in ASP.Net MVC
In MVC we already have a layered architecture then why do we need to apply further layering or design patterns? Firstly, a layer is a grouping of software components which serve for a common cause. Now a design pattern breaks down the MVC application further to make it more manageable where independent modules are less interdependent and are pluggable. By separating these sections, each can encapsulate information that can be developed and updated independently. N-tier development is an example of SoC in which the user interface (UI) is separated from both the business layer and the data access layer. Furthermore, these design patterns can proactively solve many of the common problems.
If you are using Entity Framework then probably you have another reason. Basically Entity Framework relies on the DBContext class, which is an abstraction over the database that manages data querying as well as a unit-of-work approach that groups changes and persists them back to the datastore in a single transaction. However, DBContext relies on several managed features and flags that keep track of changes in items that have been queried from the datastore. It relies on the flags to determine the best way to persist the information. The stateless nature of ASP.NET MVC prevents the default functionality of Entity Framework from working, however. You have to choose a different method to control data flow into DBContext and thus into your database. Because some additional work must be done outside of Entity Framework, you should evaluate whether you want to do this work in your controller(s) or provide a level of abstraction between your controllers and Entity Framework
The primary data access pattern in C# is the Repository pattern, which is intended to create an abstraction layer between the data access layer and the business logic layer. This abstraction helps you handle any changes in either the business logic or the data access layer by breaking the dependencies between the two. It also enables the business logic layer to access the repository without knowing the specific type of data it is accessing, such as a Microsoft SharePoint list or a database. What the repository does internally is separate from the business logic layer.
