Develop Web forum Applications Based on ASP. net mvc Framework

I want to build a complete ASP. NET MVC forum application from start to end in this series of articles. The ultimate goal is to explore and promote the best practices for building applications using the ASP. NET MVC framework.

1. Introduction

In this article, I would like to introduce the overall goal of the forum application from a global perspective. In this article, I will discuss the importance of avoiding the bad taste of code, and how to use software design principles and patterns to help you write flexible code suitable for future changes. Finally, I will explain why I chose to use the test-driven development method to build Forum applications in this series of articles.

2. What kind of software is good?

I don't want to build any forum application just to build the forum application. My goal is to build the best forum application as much as possible.
This goal immediately raises the question: what kind of software is good? What makes one application better or worse than another? Without a definition of "good software" in advance, I cannot declare that I have built a perfect forum application.
Therefore, the following is my definition of "good software.

3. Good software is software that is easy to modify

You may need to change the software for multiple reasons:
1) You may need to add new features to an existing software.
2) You may need to modify an error in an existing software.
3) You may need to optimize existing software
4) You may need to improve the design of existing software

In general, poorly designed software is hard to change. Some software is so poorly designed that everyone is afraid to touch it. We should all have used poorly designed software. When the software is not good, you really want it to go away. Even if you have a chance, you may want to rewrite the software from the beginning.

4. Avoid bad code taste

Robert and Micah Martin describe bad software as bad code. The following code is bad, which means the software is quite poorly written:
1) Rigidity-a rigid software is such a software. When you make a change at a certain position, you need to make a series of changes to the system.
2) Fragility-a vulnerable software is such a software that interrupts the normal operation of multiple other places when you make a change at a certain position.
3) unnecessary complexity-unnecessary complex software refers to over-designed software to handle any possible changes.
4) unnecessary repetition-unnecessary repetition software contains a large amount of repetitive code.
5) obscure-Obscure Software refers to software that is hard to understand.

[Note] the above Code is well described in the famous Agile Principles, Patterns, and Practices in C # by Micah and Robert Martin. We strongly recommend that you read this book.
Note that the above Code tastes associated with all the code changes. Each of these codes will affect code changes.

5. Software Design Principles

Good software design principles will help you write software that is easy to adapt to future changes. There are several and different software design principles. For example, cunnhan and cunnhan Wiki describe 11 principles of object-oriented design:
Http://c2.com/cgi/wiki? PrinciplesOfObjectOrientedDesign.

The first five Principles of object-oriented design mentioned in this article are related to Agile Principles, Patterns, edited by Robert Martin and his son Micah Martin, the software design principles stated in and Practices in C # are consistent. In addition, Robert Martin discussed these principles on the blog opened by Object Mentor:
Http://www.objectmentor.com/resources/publishedarticles.html.

In addition, I have found two other books that provide extremely useful information about software design principles. The First is Head First Design Patterns compiled by Eric Freeman, elisw.freeman, Kathy sield, and Bert Bates; the second is Brett McLaughlin, head First Object-Oriented Analysis and Design edited by Gary Pollice and David West. Although the principles discussed in these books are not very similar to those described by Robert Martin, they are very similar.

However, the truth is that all the resources discussed above for software design principles are sourced from Robert Martin's work. Robert Martin is not the inventor of all principles, but he is indeed the first person to gather them together. The Software Design Principles are listed below:
? SRP-single Responsibility Principle
? OCP-switch principle
? LSP-Liskov replacement principle
? ISP-interface isolation principle
? DIP-Dependency inversion principle
The set of the above principles exactly corresponds to the acronyms SOLID.

The following software Design principles are listed in Head First Design Patterns:
? Encapsulation changes
? Multi-Purpose Combination less inheritance
? Programming Based on interfaces rather than implementation
? Try to achieve loose coupling between interactive objects
? Class should be open for extension, but closed for Modification
? Dependent on abstraction, not specific classes
? Just talk to your friends
? If you do not call me, we will call you
? One class should have only one reason for change

Of course, there are also many overlaps between the above principles. For example, the "single responsibility" principle is consistent with the "one class should have only one reason for change" principle. However, their emphasis is different. More details cannot be detailed here.
The true motivation for all these design principles lies in the efforts to build software that can adapt to changes. The above principles are explained separately for different principles. The ultimate goal is to create software that can withstand time testing.

6. Software Design Model

The Software Design Patterns describe the problems of the policies followed by the application software design principles. In other words, a software design principle is a good idea, and a software design pattern is a tool you use to implement such a good idea.

The idea of the Software Design pattern first came from the book Design Patterns: Elements of Reusable Object-Oriented Software. This book inspired the creation of many other books describing software design patterns.

For example, another book, The Head First Design Pattern, introduced The book by GOF in a more understandable way (The Design Patterns above: design Patterns introduced in Elements of Reusable Object-Oriented Software. This book details a total of 14 software design patterns:
? Strategy
? Observer
? Decorator
? Factory
? Singleton
? Command
? Adaptor
? Fa? Ade
? Template
? Iterator
? Composite
? State
? Proxy
? Compound

Another book that has a greater impact on software design Patterns is Martin Fowler's Patterns of Enterprise Application Architecture. This book also has a company website, which lists the models described in this book. The website is http://www.martinfowler.com/eaacatalog /.

The Software Design Pattern allows you to build your code in a pattern to make it more adaptable to future flexible modifications. For example, when building the forum application in this article, we use a software design pattern named Repository for design. Eric Evans describes the Repository mode in his book Domain-Driven Design:

A repository describes all objects of a certain type as a conceptual set (typically simulated ). Its behavior is similar to a set, but it has more detailed support for queries. Therefore, objects of the corresponding type can be added or deleted, while the systems behind the REPOSITORY can add or delete them from the database.

According to Evans, a major advantage of the Repository model is that it can help you implement "application and Domain Design and storage technology, multiple database policies, it is even a decoupling between multiple data sources." In other words, the Repository mode prevents your applications from being changed due to different database access methods.
To make our forum applications stand out from a specific storage technology, we will introduce the above Repository mode in the system. Therefore, the final design of this forum application will allow us to switch between different data access technologies (such as LINQ to SQL, Entity Framework, or nhib.pdf.

7. Test-driven development

I plan to use the test-driven development principles to build the MVC forum application in this article. More specifically, before I write any application code, I will first write a unit test for the application code.

Test-driven development will bring you higher quality code for the following reasons:
(1) Writing and testing your code provides you with a security net suitable for future changes.
(2) writing tests for your code forces you to write loosely coupled code.
(3) writing a test for your code before writing your code will force you to observe your own code from a user's perspective.

Let us analyze the advantages of each of the above features in a more detailed manner.

First, unit testing provides you with a security net that can adapt to future changes. This is a point that Michael Feathers has repeatedly stressed in his book "Working extends tively with Legacy Code. In fact, he defined the legacy code as "Simple coding without testing ".

When your application code is overwritten by unit testing, you can modify the code without worrying that the change will implement the existing functions of your code. Unit testing helps to make your code more secure for refactoring. If you can refactor your code, you can use the software design pattern to modify your code, which will produce Code better adapted to future changes.

Second, compliance with test-driven development will force you to write code in a specific way. Tested Code tends to lead to loosely coupled code. Unit tests can be performed in Isolated Code units. To build your application so that it can be tested, you need to build the application using an isolated component method.

A class is loosely coupled with another class, which means you do not have to change another class when you change the first class. Test-driven development often forces you to write loosely coupled code, because loosely coupled code can withstand changes.

Finally, writing code in the test-first mode forces you to observe your own code from the perspective of a user. By writing code in the test mode, you will be able to work from the developer's perspective that may use your code in the future. Since writing a test forces you to consider how another developer (maybe yourself in the future) uses your code, the code you finally write should be better designed.

8. The immediate interests of motu should be based on the long-term

Using the test-driven development principle to build software requires developers to make more efforts at the beginning of software development. Although it takes some time to write a test, the idea is that the effort required to initially build a unit test will be rewarded in the future.

There are two ways to make you a developer. You can grow into a cowboy or a craftsman. A cowboy can start encoding immediately. That is to say, a cowboy can build a software application quickly. However, as a cowboy, the problem is that the software must be maintained for a long time.
A craftsman is very patient. A craftsman will always develop a software carefully. A craftsman always builds unit tests very carefully and makes them cover all the code in an application. Therefore, it takes a longer time for a craftsman to successfully create an application. However, this application is easy to maintain after it is created-it is easier to modify errors and add new features to the application.

9. Summary

In short, our ultimate goal is to build an MVC forum application that can withstand long-term testing. It should not only work well now, but also continue to work in the future-even when someone needs to make changes to the application.
I want to use the Microsoft ASP. NET MVC framework to develop this forum application. The reason is that this framework makes it easier for me to write test code for a program. On the other hand, the ASP. net mvc framework itself provides the most loyal support for test-driven development from the beginning of design.