Relevant Principles of a Universal Program
factor
------------------------------------------------------------
【data structure】
level
vd client display control data structure/print/export
vcd client memory data structure
json/xml structure when td_view is transmitted
In-memory data structure for cd computation
json/xml structure during td_cache transmission
pd persistence layer data structure
rd table structure
structure
Atomic data structure string/number/date/boolean/guid/bytes/binary
Simple business data structure businessobject
Single child business data structure qjd(master,List<List<detail>>)
host
Basic properties
reference object
basic property set
reference object collection
son
Basic properties
reference object
basic property set
reference object collection
Parameter business data structure define(info,bytes)
map
base map
relationship mapping
inheritance map
basic
string/number/date/boolean/guid/bytes/binary
relation
many to one
one-to-many
many-to-many
inherit
parent
parents?
[Data/Status] entry
level
vdvcd + format/unformat
vcdpd + calculation logic/processing logic
tdcd + serialize/deserialize
cdpd + calculation logic/processing logic
tdcd + serialize/deserialize
pdrd + persistence logic
rd persistent data
[Status change range enumeration]
The state change requirements are closely coordinated with the logical category and the scene timing category, and the requirements are strict.
[There is a [dependency] relationship between states, which is considered to be a state combination, with [atomicity] and [integrity constraints], then the change of the state should consider the rigor of the combination change]
[The redundancy of the state? 】
[The existence of a state is conditional? 】
A condition for state B to be a certain state value is that state A is at a certain state value.
[The internal states of a business function have [atomicity] and [integrity constraints]]
State within functions, logic, rigor of scenarios
Monitoring, with modification?
[The states of multiple business functions have [atomicity] and [integrity constraints]]
The state, logic, and rigor of scenarios between multiple functions
Reset documents?
[Logical component type] class
Concept A concept is encapsulated into a logical component
The state and logic code owned by the concept of responsibility should be written in this logic component
【Logical Component】Object
The life cycle refers to the following scenarios to define the scope of application of logic components, when to generate, when to destroy, and to create the number of components.
The number of instances considers whether the same object is operated in different scenarios. Don't see that there is code modifying the state, and think that the object is affected.
Whether the state has a state, and if so, consider the [concurrency] situation of the logic component.
Whether the logic logic is operating its own and other places, and if so, consider the [concurrency] situation of logic components.
[logical] method
method
The code should not confuse logic and timing. The logic itself can be called at multiple times, and the logic code should be written in the logic component.
[Logical category range enumeration]
The state change requirements are closely coordinated with the logical category and the scene timing category, and the requirements are strict.
【view】
data
vd
vcd
controls
value
list of optional values
Attributes
folded state
selected state
......
colour
size
......
event
layout
[scene/timing/event/system-level behavior/function-level behavior]
Development affects all operational lifecycles
develop code
Configuration parameters
run
start up
Module Loading Global Lifecycle
run
User Login User Session Lifecycle
A business function execution (opening a function) a complete business function life cycle
Scenarios of user operations during function execution The life cycle of a complete operation within a business function
One request at a time http request life cycle
Find scenarios from requirements, analyze state and logic from scenarios
[Scenario Timing Category Range Enumeration]
The state change requirements are closely coordinated with the logical category and the scene timing category, and the requirements are strict.
system-level behavior
start up
Log in
Execution of a business function, opening a function
function-level behavior
operate
behavioral events
Program event
【Timing】
The sequence of multiple execution timings affects whether the state changes as required.
If there is no response from the previous operation on the interface, start the next operation:
mask
One action multiple events:
Another radio button control was clicked when the text lost focus.
When an event causes the backend code to execute, the timing is complicated and confusing because of multiple layers of listeners:
Interface Modification A --> Backend Modification A --> Formula Modification B --> Formula Modification C --> Formula Modification A?
When to go from control to model?
When does it go from model to control?
When are some other states logged?
application
------------------------------------------------------------
Parametric design
document entry
List query
......