ASP. NET design mode

Professional ASP. NET Design Patterns

Why Study Design Patterns?

Apply the design patterns, principles, and best practices in your ASP. Design patterns and principles support loosely coupled, high cohesion code, which improves the readability, flexibility, and maintainability of your code.
There is no reason to repeat work for tasks that already have a good solution.

Famous architect Christopher Alexander Christopher Alexander once said:
Each pattern describes a recurring problem around us, and the core of the problem solution so that you can use it again and again without having to do repetitive work.

John Lennon "No problem, only way out"

. The need for net developers to learn
Microsoft's RAD (Rapid Application Development) development tool Visual Studio.NET quickly publishes a single Web application. The simple drag-and-drop and WYSIWYG application design interface allows people to get started quickly, and a consistent programming model also facilitates the migration of desktop application developers to Web application development. In addition, because the encoding mode and design mode can be easily switched, the graphic designer in the design phase can be seen with the runtime close to the interface, without the need to frequently run debug mode or refresh the Web page, which allows the graphic designer to participate in the application development, thus improving the development efficiency. However, this cured form-form application design pattern is also inherent in congenital defects. As business requirements change and scale up, if you still put all of your business logic in the post code, it will make your code bloated and there are a lot of duplicate code. At the same time, this Web Form design is not conducive to the use of AJAX technology in applications, it is difficult to share code between Web Forms and Web services programs. Mastering the design concepts and implementation tools mentioned in the book is beneficial to better understanding the concepts in the ASP.


Patterns and Design principles

Design patterns are high-level, abstract solution templates. These patterns can be thought of as a blueprint for the solution rather than the solution itself. It is not possible to find a framework that can be easily applied to an application, but rather to implement design patterns by refactoring your own code and generalizing the problem.

"Foursome" (GoF). They included 23 design patterns and grouped them into 3 groups.
Create pattern (creational): Handles object construction and references.
Structured mode (structual): Handles the relationships between objects and how they interact to form larger, complex objects.
Behavioral mode (behavioural): Handles communication between objects, especially in terms of responsibilities and algorithms.

Patterns are an effective way to describe solutions to complex problems. With solid knowledge of design patterns, you can communicate quickly and smoothly with other members of your team without having to dwell on the underlying implementation details. The pattern is language agnostic. The knowledge gained through learning patterns will be applied to any good object-oriented language used in the specific programming.

The purpose of design pattern is to reuse the solution. Of course, not all problems are identical, but if a problem can be broken down and the similarities between it and previously resolved problems can be found, these solutions will be used. Even if you think your problem is unique, you should be able to generalize it to a certain level by breaking it down into a number of basic elements to find a suitable solution.

The name of the design pattern is useful because it reflects the behavior and purpose of the pattern and provides a common vocabulary for people to brainstorm solutions.

Traps: Trying to apply design patterns to everything you do, but ultimately the effect is the opposite of the original design pattern (that is, making things simple). A better way to use the pattern is to find a solution that is right for it by identifying the basic problem that is being tried to solve.


Design principles

The design principle forms the basis for the design pattern to be built. By following proven design principles, your code base becomes more flexible, adaptable to change, and more maintainable.

1. The principle of simplicity (KISS)
A common problem in the field of software programming is the need to complicate the solution over and over. The goal of the kiss principle is to keep the code concise but not too rudimentary to avoid introducing any unnecessary complexity.

2. Do not repeat yourself (DRY)
The purpose of the dry principle is to avoid repeating any part of the system by pulling out the common parts and putting them in a separate place. This principle involves not only code but also any logic that repeats in the system. Ultimately, any part of the system should have only one representation of knowledge.

3. Talk without asking (Tell, Don ' t ask)
The principle of "telling without asking" embodies both the encapsulation and the idea of assigning responsibility to the right class. This principle requires that you tell the object what action you want them to perform, rather than asking questions about the state of the object and then you decide what action you want to perform. This principle helps to match responsibilities and avoids tight coupling between classes.

4. You do not need it (YAGNI)
The Yagni principle refers to the need to include only the functionality required by the application, rather than trying to add any other functionality that you think might be required. Test-driven Development (TDD) is a design methodology that adheres to the Yagni principle. The purpose of TDD is to write tests to verify the functionality of the system, and then just write the code that allows the test to pass.

5. Isolate the point of interest (SoC)
The SOC process breaks down software into a number of different functions, each of which encapsulates unique behaviors and data that can be used by other classes. Typically, a concern represents a function or behavior of a class. Dividing a program into several separate responsibilities significantly improves code reuse, maintainability, and testability.

S.O.L.I.D. Design principles are a set of best practices for object-oriented design. The term s.o.l.i.d. From Robert C. Martin (friends affectionately called him Uncle Bob) The book Agile Principles, Patterns, and practices in C # The first letter of the names of the 5 design principles collected.

1. Single responsibility principle (SRP)
The SRP principle remains highly consistent with the SOC principle. It requires that each object should only be changed for one element and that there is only one responsibility focus. By following this principle, it is possible to avoid the design problems of the monomer class (like the Swiss Army knife in the software field). By keeping each class concise, you can improve the readability and maintainability of your system.

2. Open closure principle (OCP)
The OCP principle requires that classes should be open to extensions, and should be closed for modifications, so that you can add new functionality and extend classes without changing the internal behavior of the class. This principle strives to avoid destroying existing classes and other classes that depend on it, because it creates a ripple effect on bugs and errors in the application.

3. Richter replacement principle (LSP)
The LSP principle states that you should be able to use any inherited class to replace the parent class and let it behave the same way. This principle is consistent with the OCP principle: it ensures that inheriting classes do not affect the behavior of the parent class, in other words, inheriting classes must be substituted for their base classes.

4. Interface separation principle (ISP)
The ISP principle focuses on dividing the method of the contract into several responsibility groupings and assigning different interfaces to those groupings so that the client does not need to implement a large interface and a bunch of methods that they do not use. The purpose behind this principle is that classes that use the same interface only need to implement a specific set of methods, rather than implementing a large monolithic method interface.

5. Dependency inversion principle (DIP)
The purpose of the dip principle is to isolate the classes that you have written from the specific implementation so that these classes rely on abstract classes or interfaces. It advocates programming for interfaces (rather than implementations), which ensures that the code is not tightly coupled to an implementation, which increases the flexibility of the system.

6. Dependency Injection (DI) and control reversal (IoC) principles
The dip is closely related to the DI principle and IOC principles. DI provides the underlying class or subordinate class through a constructor, method, or property. With the DI principle, these subordinate classes can be reversed to interfaces or abstract classes, thus forming a loosely coupled system with high testability and easy modification.

In the IOC principle, the control flow of the system is reversed compared with the procedural programming method. An example of this principle is the IOC container, which serves to inject services into client code without having to specify a specific implementation for the client code. In this instance, control inversion refers to the behavior of the client acquiring the service.

Fowler's Corporate Design model
Martin Fowler's book Patterns of enterprise Application architecture is a reference book on best practices and patterns for building enterprise-class applications.

1 Domain logic mode
3 Common ways to organize business logic: Transaction script (transactional scripts), active record (activity Records), and domain model (domain models).

1. Transaction Script
The Transaction script pattern organizes business logic in a linear, procedural way. It maps fine-grained business use cases to fine-grained methods.

2. Active Record
The Active record pattern organizes the business logic in a way that closely matches the underlying data structure, which is the object that represents the rows in the table.

3. Domain Model
The domain model pattern is an abstraction of a real-world object. Model data and behavior at the same time. There can be complex relationships between objects that match the real realm.



2 Object Relational Mappings

The enterprise model required to support persistent infrastructure code.

1. Unit of work
The unit of work (working unit) mode is used to maintain a list of business objects that have been modified (added, deleted, or updated) by a business transaction. The Unit of work mode then coordinates the persistence of these changed objects into an atomic action. If a problem occurs, the entire transaction is rolled back.

2. Repository
The Repository (Resource library) pattern is largely used for logical collections of objects, and their more known names are called aggregations (aggregate). It acts as a memory collection or warehouse for business entities, abstracting the underlying data infrastructure entirely.

3. Data Mapper
The data Mapper mode is used to extract information from raw data to generate objects and to transform information in business objects into databases. Business objects and databases do not understand each other.

4. Identity Map
The identity map mode monitors each object loaded from the database, ensuring that all objects are loaded only once. When the object is later requested, the flag map is checked before retrieving from the database.

5. Lazy Loading
Lazy Loading (lazy load or lazy load) mode defers the process of acquiring resources until the resource is really needed.

6. Query Object
The Query object mode is an implementation of the GOF interpreter (interpreter) design pattern. The query object acts as an object-oriented query abstracted from the underlying database, referencing properties and classes rather than real tables and columns. In general, you also need to use a translator object to generate native SQL statements for querying the database.


Web Presentation mode
A pattern that separates the domain from the presentation logic and allows the presentation layer to test effectively. The task of these patterns is to separate the logical concerns that are used for presentation from the business logic concerns. Asp. NET represents the patterns that need to be covered:

Model-view-presenter (Model-view-representation).
Model-view-controller (Model-View-controller).
Front controllers (Front controller).
Page Controller.

Other business models in Fowler's writings
1. Null Object mode
The null object mode is also known as the special case (special cases) pattern, which acts as a return value instead of returning NULL to the calling code. An empty object will share the same interface as the expected result or inherit from the same base class, reducing the need to check for null conditions everywhere in the code base.

2. Separated interface mode
The separated Interface (stand-alone interface) mode requires that the interface be placed in an assembly or namespace that is independent of the implementation. This ensures that the client is completely unaware of the implementation and is able to follow an abstract-oriented programming rather than an implementation-oriented approach and a dependency inversion principle.

3. Gateway Mode
Gateway mode allows clients to access complex resources through a simplified interface. The Gateway object basically wraps the resource API into a single method call that can be used everywhere in the application. In addition, it hides all the complexity of the API.

--------------------------------
TDD (Test-driven development, test-driven design) is not, as its name suggests, more of a design methodology than a test strategy. The main idea behind this design methodology is to use tests to shape the design of the system. When you create a software solution, you first write a test program that causes the test to fail to assert some kind of business logic. Then write the code to let the test pass. Eventually, the refactoring is done to clean up all the code. These three steps have been called red-green-Reconstruction (red-green-refactor). Red and green refers to the test framework used to display the color of the test pass and test failure.

By going through the TDD process, you will eventually get a loosely coupled system with a set of tests that confirm all the behavior. A byproduct of TDD is that these tests provide a document that describes what the system can and cannot do. Because the test is part of the system, it is never obsolete, unlike written documentation and code comments.

Test driven Development:by Example,kent Beck
The Art of Unit Testing:with Examples in. Net,roy osherove
Professional Enterprise. Net,jon arking and Scott Millett (Wrox Publishing)

DDD (Domain-driven design) is a set of patterns and principles that help build applications that reflect the understanding of the business and meet the needs of the business. In addition, it is a new way of thinking about developing methodologies. DDD is modeled as follows: First modeling the real world by fully understanding the real world, and then putting all the terms, rules, and logic into some kind of abstract representation of the code (usually in the form of a domain model). Although DDD is not a framework, it does have a set of building blocks or concepts that can be integrated into a solution.

Domain-driven design:tackling complexity in the heart of Software,eric Evans
Applying Domain-driven Design and Patterns:with Examples in C # and. Net,jimmy Nilsson
.net domain-driven Design with C #: Problem-design-

BDD (Behavior-driven design, behavioral-driven) is considered a result of the combination of TDD and DDD. BDD focuses on the behavior of the system rather than just testing it. The specifications created when using BDD can use languages that are ubiquitous in the real world, enabling both technical and business users to benefit.

The documentation generated when using BDD to write specifications allows the reader to understand what behavior the system behaves in various situations, rather than simply verifying that each method is performing the work that they should do. By combining several aspects of DDD with the core TDD concept, BDD will meet the needs of both business users and technology users. BDD can be performed using a standard unit testing framework, but the dedicated BDD framework has emerged and BDD is about to become the next big event.

How to learn

The

Name and intent reflect the purpose, usage, benefits, and motivations for using the pattern or principle. A
UML diagram
presents a graphical representation of the structure of a pattern or principle. Graphical representations are used to display a generic solution template and its implementation.
Code Implementation

How to select and apply design patterns
cannot use them without understanding the pattern. Start by broadening your knowledge and learning patterns and principles from an abstract to a concrete approach.
Whether it is necessary to introduce the complexity of design patterns. You need to measure the time required to implement a pattern and the benefits that the pattern can bring. Remember the kiss principle. The
speaks of a problem generalization, and a more abstract way to identify the problem is being handled. Learn how each of these patterns and principles is written. and understand whether the problems you need to solve are in line with a particular pattern or principle that you are trying to solve. Design pattern is a high-level dared solution, try to abstract the problem, do not focus too much on the details of specific issues. The
understands patterns with similar properties and other patterns in the same group. The
encapsulates the changed part. Understand what may change in your application.
After selecting a design pattern, ensure that participants in the named solution Use the language and domain language of the pattern. Fedexshippingcoststrategy use policy mode to price different courier companies