javascript - js to write a similar product management backend page, what design pattern is easier to expand and maintain?

Question

Write a background management page, using a simple singleton mode. Similar to

var xxx = {
  method1: function(){}, 
  method2: function(){},
  ...
}

I would like to ask someone with experience to write this kind of project. How to organize the code structure to make it easier to expand and maintain.

Answer 1

Backend management will definitely involve a lot of additions, deletions, modifications and checks. You can handwrite an MVVM

Answer 2

General design patterns are used for the maintainability of the program. Specifically, they strive to preventively handle some parts that are prone to change, so that the original code should not be modified too much in later maintenance, especially Logic code has been integrated. With the above understanding, we can think about it now. Your project will require a lot of additions, deletions, modifications, and searches. Deletions may be simpler, and it is unlikely that any special design patterns will be used. Let’s start with the increase:

1. Adding products: It is nothing more than adding and prompting various parameters. We can at least be sure that there will be changes in the future when adding new products. For example, we may only have one product at the beginning. Name, an inventory, a text introduction, a slide, etc. But later, the product manager of God said that the projects we did were not halal enough. The cultivation users in our world may have more needs and need to add a few more filling options, such as Provide a column for displaying prices when customers publish products of different specifications, or add a column to facilitate customers to display different discount prices during different holidays, etc. All in all, the requirements will only increase. If you don’t want to be annoyed by such nonsense later, you need a good design pattern to deal with related issues. One mode I can provide you here is the intermediary mode (which can avoid coupling between modules as much as possible. To add a new column, you only need to pass the encapsulated module into the intermediary function, and don’t care about its internals. How to deal with it, all you need to do is to provide a unified interface), no matter how many parameters are added in the future, you only need to complete the relevant logic modules.

2. Still adding products: After using the above function for a period of time, your product manager may have perfected the golden elixir and is about to show off his power. However, you just happened to be trapped in it again. This time the demand may be It is "to provide corresponding parameter filling and selection functions according to different product types." For example, your electronic products may need to fill in detailed parameters, but game coupons do not. What we can use at this time and the most commonly used one is "object-oriented", also called the template method pattern, which is simply inheritance and rewriting. One father, a bunch of sons, no ambiguity, whoever should get on will get on. This mode is relatively simple. The problem is that the complexity of the code can be a bit painful.

3. Modify products: In fact, most situations are similar to adding new products. We may need to consider certain special needs. For example, the user is currently modifying product information, but does not want it to take effect immediately after submission, and hopes to be able to manually control the release of relevant information at any time in the future. At this time, you provide an additional button on the page to switch between information publishing and information saving states. It is used to distinguish your different processing methods of data in the two different states. There may even be scheduled releases in the future. etc. At this time, you may need to use the strategy pattern or the state pattern to handle behavior methods under different strategies or states.

4. Check products: The simplest is to add different filters (such as region, type, price, etc.), the same as point 1. Or you need to perform a search on some data content that has already been read. For example, the products that match the keywords "I want to cultivate immortality" are displayed, and the others are removed. Because you may need to match information in different columns one by one, you can use the chain of responsibility model.

In general, I have listed some common design patterns, but there will be more problems encountered in the actual development process, for example: You now need to update the function of new products, and the demand is Every time before the user adds a new product, a test must be done to determine whether the user has filled in a similar product template before. If so, the user will be prompted to apply it directly. If not, the user will not be prompted. But you may seem to feel that you are about to overcome the disaster, because this module was previously responsible for your colleague, and you don't want to read his source code. At this time, you may need to use the decorator pattern to update the relevant code. Try not to modify the source code while ensuring normal functionality. . . . . There are many such examples, and the key is to do things right. As for whether you should consider so many things before starting the project, I don’t think it’s necessary, because you can’t think it through at all. Sometimes there is a gap between what you think and what you will actually encounter. You can only choose some obvious ones. Avoidance, it’s like I’ve written so much for you, but I’ve only stayed at some of the more obvious parts, and I haven’t written about this type of project yet, so I can only guess at the specific problems I’ll encounter. . So don't get too entangled in the pattern issue. It may be better to refactor the code when you come to your senses.