Some questions about the design and development of Django Web application architecture

1, regarding the stratification, has done the traditional JEE application the schoolmate certainly knew the JEE application will divide many design layers. According to the traditional Web application architecture design generally from top to bottom of such a few layers (too lazy, not drawing): The Web front-end layer, the Web backend interaction layer, the business layer, the basic data infrastructure layer, the Web front-end layer in the browser by JavaScript to do, temporarily do not table, data facilities layer, Django data operations close to the active record mode, quite perfect, basically no more packaging processing, focus on the interaction layer and the business layer, the interaction layer mainly accept the request data, call the business logic to complete user interaction.

2, on the business layer of independent existence problem, Django business layer independence is not necessary, to tell the truth, I just started to use it for Internet applications, one is the Internet scenario is weak business environment: business logic is relatively simple, and the second is the Django Data facility layer is very perfect, to directly do the interaction layer, Code volume is also very small, but in the process of product system constantly bloated, the scale and structure of the system constantly complicate the process, the system structure management requirements will gradually emerge, this time on the business layer independent implementation of the design requirements will gradually become apparent. The product is changing, the system is changing, the requirement of the business layer's independent reconfiguration is gradually appearing under the changing scene, of course some system one step requirements are relatively high, perhaps from the beginning to do the independent business layer.

3, the business layer design implementation problem, Django business layer in what way exist, first enterprise application architecture model says active The business layer in record mode should be put together with models. Second, Django actually provides a standard way to implement the business layer, which is to extend the Models.manager and then pass the instance to the objects object of the model class. The advantage of this approach is that the reference directly from the model class can be In order to invoke the business logic method, the disadvantage is that it is a little too close to the specific model class, and for business logic involving multiple model classes, it can be defined directly in the models module in the form of a function.

4, the interaction layer did what, first Django in the input validation is done in the Form class definition code, simple createupdate operation can also be done directly with the form of save, then talked about the interaction layer to invoke the business layer of the problem, in fact, the business logic is relatively complex behavior, On the invocation, the method calls the natural to pass the parameter, in the Interaction Layer Implementation form form object initialization and input validation passed, the form object to the business layer is more appropriate, 1 is the form of data is cleaned and filtered processing, 2 is passed a form object, such an effect similar to the DTO in Jee, The transfer process is relatively clean.

5, where the transaction layer is placed, when the business logic involves multiple data read and write, the transaction characteristics are very important, first Django provides the transaction characteristics of the use of diversification, first with the transaction decoration view function is a once and for all lazy approach, and the nature of the transaction is actually related to the business, The addition of transaction decorations on the business layer approach is a more rigorous design implementation. This nested multilevel transaction is perfectly supported in the Django Transaction feature.

6, about exception handling, first Django itself provides 500 error page mechanism, that is, after the exception of the error page to show that we do not care, we need to deal with the exception of the tube is what? These anomalies are related to normal business logic: when they happen, The business logic shifted to another normal processing branch.

7, Django signals an application scenario, Django's signals mechanism is not an asynchronous message mechanism, he basically close to the adorner, is a synchronous hook mode, synchronization limits its business design scenarios, However, in the implementation of the design is still useful: the import of Python has a deadlock cycle problem, Linux execution environment is more stringent, such as string encoding and import loop problems are more likely to occur than Windows, import loop this issue, From the point of view of design needs strict architecture layered design, call between the same layer to limit, cross-layer reverse to be absolutely forbidden, but any module call is complex, it is impossible to absolutely satisfy the constraints, singals hook mechanism, isolation le caller, should be able to solve cross-layer reverse call import problem. (This scenario has not been tested for actual application)

8, again talk about the structure of the circular import solution, in Django cross-app model dependency is likely to be more common, the same level of dependency or even reverse the direction of the structure of the inverse dependency can lead to the import cycle, the inverse of the architecture layer reverse dependence of this phenomenon should be avoided as far as possible, For data dependencies between layers, you should try to stick to the view and all the model is within the same app, so how can cross-app dependencies be solved? 1, the front-end asynchronous dependency, can be loaded on the front-end of the dependent data, asynchronous data provider of course in the model in the app, 2, template tags, the normal label will certainly not be relied on in other py files, it is normally only the top of the template code to rely on, this situation is certainly impossible to cycle. 3, the model class between the foreign key dependence cycle, this is more deadly, but the solution is also very simple, the use of string form reference model will directly avoid import, there is no implementation dependency, However, this approach requires that the app referencing the model be added to Settings's Installed_apps settings.

9, Django session If you place a list of such reference data, in the modification operation, should be assigned to take out, modify the operation, and then assign the value back, the original operation may be invalid. Background technical reasons may be because of the session serialization reason

10, the front-end form does not have the model field must be in the form definition inside exclude out, only in the model definition blank and null can only do the definition of validation rules, can not prevent malicious users to construct false form fill these model fields. Post-Supplement: Use the fields meta-information definition to be a little better than exclude.

11, a special advantage of Django code encapsulation: When the encapsulated code fragment of the Operation object is a model instance object, this time should consider referring to the design of the active record package, this code is encapsulated into the model class instance method, This encapsulation is more nice than the manager method package, which should be said to be the preferred package for most business logic, at least in a better way.

Some questions about the design and development of Django Web application architecture