About the architecture of a recently developed SaaS Software

Recently I had the honor to participate in a software-as-a-service (SAAS) development and programming for two weeks. The overall feeling is desirable, but more is that the running speed is slow and the development efficiency is low. The following is a brief analysis.

The software uses. Net 3.5, development tools use vs2008, and database SQL 2005. The system is also layered, with the ASP. NET presentation layer, business management layer, data access layer, and databases.

 

Microsoft. Practices. Unity is used between the presentation layer and the business layer to implement an Interface Conversion when the presentation layer calls the business management layer. In the presentation layer, the interface corresponding to the objects in the business management layer is used for programming. When the program runs, the Unity tool calls the real business objects. The domain model that transmits data between the presentation layer and the business layer is generally named xxxinfo, but I feel more like a "entity class ".

 

The data access layer uses ADO. NET Entity Framework, a so-called ORM tool recently released by Microsoft. Of course, drag the table structure into Vs and set the ing between some entity models and data models, you can access all the generated data without writing the code.

 

The business layer and business management object are generally named managexxx to implement query, add, modify, and delete (crud) packages, such as add or modify operations, first, call the database into EF to create an EF entity model object. If it is new, create a new one. If it is modified, get one by ID, the Info Object encapsulated in the UI Layer is mapped to the object model object one by one, and the savechanges method of EF is called. Of course, the data is mapped from the EF entity model to the Info Object one by one.

 

This is the overall architecture. In my personal opinion, what is wrong with doing so.

 

Database EF is a technology just launched by Microsoft. After reading msdn, it seems to be good, but it is really useful. I don't think many people use it well. You are still familiar with the traditional ADO technology, in terms of some special functions, in the business management class, some ea LINQ syntax, the EA entity syntax, And the ea SQL are not used much. Access EA to these three technologies, because I am not familiar with the technology, I may feel very inefficient at some times. After I developed it, 1st operations on a record are very slow. For example, to update an order, assume that the main table of the Order is associated with many other tables, such as the customer, salesman, payment method, currency, exchange rate, transportation method, and so on, or take this object, if there is no "delayed loading", I do not know how many objects to load, and if the object design is poor, it will be troublesome to load cyclically. New technologies have slowed down the pace for new recruits, so they are worried about efficiency in the future.

 

Another point is the so-called domain model xxxinfo class. In our mind, the real domain model of object-oriented technology is an object that contains relevant objects. The current domain model contains a simple set, get, occasionally, some object information used on the interface is added. Therefore, I say this is an entity class that is similar. The most puzzling thing is that the fields in these info classes are original fields, however, EF is called as an object. For example, the Order table contains the custid field. EF contains order. Customer, while info is the custid field. In this way, the data must be transferred to order. Customer. custid. When writing data, new customer (custid) is required. Does it feel useless? When retrieving data, the info class only needs custid, now I estimate EF will get a customer data object from the customer table based on the ID. When writing data, there is only custid In the info class. To meet EF's storage needs, a customer data object must be obtained based on custid and then assigned to the customer object of the order data object, because they are associated. It is like putting the cart before the horse ".

 

The most unpleasant thing is the crazy development efficiency. Let's think about how many features we need to write manually to implement a function. The info class should be handwritten, and the methods for converting from the data model to the info class should be manually written. The methods for converting from the info class to the data model should be manually written, and the interfaces of the business management class should be manually defined, the implementation class of the business management class should be written manually. Of course, the business program should not mention that 20 or 30 fields in a table are normal. Let's take a look at how long it will take to write a function, last week, I wrote a sales order function, which took four days. In addition, there are still a lot of codes and functions that reference other people's purchase orders. I copied a lot of code, so I could barely complete it after repair, modification, and modification. In addition, the development experience is quite uncomfortable.

 

Because there are too many places to write manually, there will be too many chances of problems in the future. If you don't think about it in one place, how much time will it take to re-compile and debug? Alas, no patience.

 

Recently, I was reading csla again. net Framework, I think this framework is really good, mobile business objects, distributed deployment, especially some code automatic generation tools, I feel that with the standard, the code is automatically generated, the development efficiency is fast, powerful functions, absolutely different development experience. Wait to translate an article, the code will automatically generate an article for you to see, try this software last night, it is not generally powerful. And it's still open-source.