Importance of Software Framework Design

Last week, I participated in the company's Saas technology training. In the past two days, I was looking at Windows security and SQL server security technologies. I mainly wanted to deploy a winform project of the company because of this project, there will be a large number of end users, and billing is also involved. Therefore, there is a high requirement on data security, and database problems will directly affect the company's operation and image. The importance can be imagined.

In the beginning, due to the time relationship, the Framework Design was relatively simple, but the layer was implemented logically. The physical layer was just a front-end and a database. Therefore, to restrict the use of a database, you must be a legal user. In addition, the database connection is valid for legal users. It is also a problem to prevent internal access to the database. I initially thought that the end users of domain management could be blocked, and SQL server security would also adopt domain account users. This can block the outside, but it is still a problem internally. My internal idea is to adopt a Domain Restriction policy and do not allow the client to install software, so that users cannot manipulate the database through other software, security will be better, but people with better technical skills will always find any vulnerabilities. It is difficult to prevent external attacks.

Therefore, the importance of software architecture design. If we can consider layering at the beginning and there is a business layer in the middle, of course we can physically separate them, then the database only needs to be open to the servers at the business layer, end users do not know where the database is, so the security will certainly be good, there is no way, experience is also accumulated.

For the next project, you must consider the distributed architecture, that is, physical layering, to provide powerful scalability. This problem was also raised during the last SaaS training. I have read about csla. Net some time ago and made it clear about the distributed extension. For ASP. NET, the web layer calls the business layer through proxy, and the business layer proxy performs database operations based on the incoming business objects. In this way, the physical web layer and the business layer can be divided into two servers, plus the database, which is undertaken by three machines. The front-end calls the business layer and can use several communication methods. Currently, there are Web Services, remoting, and COM + Enterprise Services. Recently, the 3.5 version has joined the WCF.

Such a framework can be deployed in a large or small way. If you call the framework on a machine at a cost, you can skip the proxy to maximize performance. To implement large-scale applications, you can use the Web farm to achieve load balancing on the web layer. Each web server corresponds to a business processing server, all business processing servers, and then calls the database layer, through the cluster technology, the database layer can imagine how powerful an application is composed of five servers on each layer and three-layer and 15 servers.

For platform software such as SaaS software, scalability must be taken into account at the beginning of the architecture. I think csla is used. NET framework to develop software, will certainly meet the needs, in addition to the use of code generation tools, today I have studied the csla template that comes with code Smith, through code generation, it's really convenient.

I have seen all the software frameworks that I feel most satisfied with. After all, it is better for foreigners to consider such a framework. Standing on the shoulders of giants, we will soon succeed. It is strongly recommended that everyone who works on the software architecture can read <Expert C #2005 Business Objects>. There are many ideas in this book, which deserves our reference.

I think we need to think about software. I think we have accumulated a lot of experience as we continue to work on projects, so we can avoid detours. We should try our best not to build our own wheels.