I now have some tool classes. Should I do my own framework?

Tool class is good. It provides mechanisms but does not provide policies. This is a linux programming philosophy. As I mentioned before, Gamma in GoF also prefers libraries rather than frameworks in an article.

I don't pay much attention to this now in programming. Of course, because I have to work in the existing languages, libraries, and tools, it is natural that something similar to the framework will often be formed, but I will often ask myself if I can avoid it: if de-frame will not bring more trouble, I will remove it.

Cognition

Is the framework completely useless? None. It indicates that it must have its own purpose. We have a business with its own models, rules, and processes. But some uncertain things will come in the future, so we have to have a framework: this is the case of a graphical interface. [1]

But more often I find that there is actually a simpler way to bond some elements in the mechanism or function set. This is very simple, and the workload for restructuring is also small when changes occur. And it does not affect reuse, or it can be reused better (because the granularity of each part is relatively small ).

The key is to really understand what is the essence of the business we want to deal. This actually doesn't mean what this business is for humans, but that this business is in the existingCannot discardIn the abstract layer.

For my current goal (remember this is changeable), this abstraction layer includes the computer itself, the operating system, the base library, and general protocols. It should be noted that the abstraction layer is not true abstraction in a sense, but concrete. For example, if you have 2 GB of memory instead of an infinite Turing machine tape, for example, the hard disk is slow. For example, the software compromises based on the actual situation.

It seems that there are all abstract layers, so the above emphasizes that "You cannot discard ". I used to be very good at. NET.. NET and a series of environments around it are the most comfortable programming infrastructure I have ever used. I am also very familiar with ASP. NET and can basically figure out every detail. But one thing I finally learned is that it is not a part that cannot be abandoned.

At the end of this talk, it is a trade-off between the convenience it provides and the constraints or troubles it brings to the specific part according to its author's wishes. All Web Services basically follow certain protocols and document formats (for example, HTTP/HTML is an abstract layer, but we cannot discard it, otherwise no one can use our stuff) generate a string based on parameters.

Decision Making

When HTTP and HTML are finalized, it can be said that all the planning is done: on this basis, there are enough agreements and consensus on the paper, finally, it becomes a mechanism and policy. As long as they are not destroyed, things can be played; the rest is added (This is in contrast to the necessity of the graphic interface framework), you must "give a reason first ".

Many people do not want to look at the problem like this, including when I first fell victim to ASP. NET. This makes us feel like we are going back to the ASP era, which is a kind of backend. If we communicate with others, it seems like we are not motivated. I don't know how we create this kind of feeling, maybe because we are not confident and firm enough when we have little experience. [2]

One thing that must be realized is that we cannot convince ourselves that ASP. NET or XX is used without answering this question. This actually shows who ASP. NET is. More, we must answer: Is my current situation the same as "everyone? This answer determines whether or not we should do it: that is to say, technical selection. Since the word is used, the workload of the word is involved.

We need to make it clear that we choose "type" instead of several finished products. Only by comparing the degree of conformity between the "type" and the finished product can we draw a conclusion: Maybe it is very comfortable to make some libraries on people's frameworks, maybe it is to build a framework of its own, it is more suitable for your own needs. Or, no policy is defined, and a bunch of mechanisms are provided to assemble on site according to the problem.

Now we have decided to build a framework. We have been using ASP. NET. The key is that we can't play a big deal in a circle drawn by others. Of course, our goal is not to play with flowers, but to feel the needs first. So I feel the demand. I think ASP. NET has bound me. What should I do?

Run

First, make it clear: if we acknowledge that the framework is useful, I think the framework should be as small as possible (or as empty as possible). In most cases, it should be something that can be overturned at a lower cost.

In addition, it is worth noting that the function cannot be combined with it, because in this way, we will obtain the "Beautiful solid bastion" called by Linus in the highest probability ", A real (relative to the hypothetical) change will take a rest. Personal experience is to focus more on the clarity and simplicity of local input and output, less on exquisite object interaction, and make the organizational part a flexible bonding layer.

Specific to the ASP. NET. My advice is to do it on Handler and Module. I don't want to use anything more advanced than Microsoft's: WebForm, MVC, this is not something useful for framework authors, and they force you to be satisfied.

First, we must have freedom to draw out the imaginary things that we want to create based on what we should have. On the other hand, we are confident that we will always be stuck with such concerns.

Some people think that the compiler is hard to write and the operating system is hard to write. Some people think that ASP. NET authors are hard to write. What I can say is that anything implemented by ASP. NET is not difficult (this makes the work evaluable ). In terms of technical details or design.

For the latter, it is just the authors of ASP. NET who have collected a number of requirements and come up with the idea that this should be the case. We should not be affected by this: unless we are not sure that our needs are true, we will not make any worse decisions than them. In particular, the clearer and more specific the goals, the more advantageous our design will be.

On this basis, how can we get confidence? We don't start it. We are always there to prepare and never have confidence. In fact, from the very beginning, for example, inheriting the Handler interface and printing a line of Hello world can greatly enhance confidence: The rest is how to replace this line with something more useful: how to organize this part is your framework.

Last

Of course, we must have clear requirements, instead of being influenced by others. I want to make an MVC, And I want to better understand those Entities; what we read is more of a reference. If you think about it, you can throw it for the moment. The key is that I have an idea that makes it easier for us to live (at least for the business I am focusing on.

Finally, programmers or developers are often programming enthusiasts. In this case, as long as you are idle and have nothing to do, it is always good to do something yourself, even if it is just a prototype. We just need to remember that first, we need to determine what problems we need to solve: the benefits of the empty gun will be much smaller.

 

------

 

Note [1]: Compare the differences between the graphic interface framework and the graphic library. The former must first plan something to give the end user an intuitive and unified feeling.

Note [2]: in other words, if you are confident at the beginning, you may miss a lot of things. In the end, it is not necessarily an old man. Sometimes it is necessary to repeat the process: Someone may naturally be able to quickly and directly filter out useful information to eliminate useless information; but at least I know that I am stupid, many times you have to give it a try to learn something. Of course, stupid people can also learn better judgment methods.