asp.net MVC contact Manager Development Tour Iteration 4

Iterative 4 is loosely coupled with design patterns

This iteration

This is the fourth iteration of the Contactmanager, and in this iteration we will refactor the application to loosely decouple its coupling with a reasonable use of the design pattern. Loosely coupled programs are more resilient and easier to maintain. When an application is faced with changes, you only need to modify one part of the code without a large number of changes to the far-reaching of the associated code that is heavily coupled to it.

In the current Contactmanager application, all the data storage and validation logic is distributed in the Controller class, which is not a good idea. In this case, once you need to modify part of the code, you risk adding bugs to other parts. For example, if you need to modify the validation logic, you must bear the risk of the problem with the logic of the data store or controller part.

(srp-the principle of single responsibility), in the case of a class, should focus only on doing one thing and only a reason for it to change. Coupling controller, validation, and data storage logic together is a serious violation of the SRP.

Changes in demand, sublimation of personal ideas, and unexpected situations are so frequent that you have to make some changes to the current application: Add new features to the application, fix bugs, and modify the implementation of a feature in the application. As far as applications are concerned, they are difficult to be in a state of immobility, and they are constantly changing and improving.

It is now the case that the Microsoft Entity Framework is used in the Contactmanager application to process data communications. Imagine that you've decided to make some changes to the data storage layer implementation, and you want to use other options: such as adp.net data Services or NHibernate. Since data storage-related code is not independent of validation and controller code, you will not be able to avoid modifying code that should otherwise be irrelevant.

On the other hand, for a loosely coupled program, the above problem does not exist. A classic scenario is that you can switch data storage without having to control the validation logic and the them code in the controller.

In this iteration, we will leverage the benefits of the software design pattern to refactor our contact Manager application to meet the "loose coupling" requirements we mentioned above. Although after this, our application will not be any different from the past, but we can easily control its future maintenance and modification process.

Refactoring refers to the process of modifying the code and improving the internal structure of the program without changing the external behavior of the program.

Using repository Mode

Our first change is to use a design pattern called Repository to improve our application. We will use this pattern to separate the code associated with the data store from the rest of the logic in our application.

To implement the repository model, we need to do the following two things