What does your application code look like?
When developing the platform, I consider it extremely important to pay special attention to the simplicity, clarity and convenience of working with the application code. Having tried different approaches, I want to share handy recipes from my experience.
By application code is meant code that is directly related to the business logic of a particular application, while, unlike the kernel (framework, platform), such code is maximally subject to change and in large projects can be the lion's share of the project. The speed and quality of development in the most essential way depends on the convenience of the application developer.
For example, the Brainfuck Hello world language looks like this:
And here are our criteria for convenience:
A typical example of an applied task is the development of a button with some action by pressing it. The button can be on the form , on the grid or in the system menu. Depending on the location, it has a set of available input parameters (what kind of form? What kind of grid? Which records are selected?) And a set of possible actions (update, change, open, etc.), we call their totality context.
')
In our system, to create a button, you need to develop a class of this button that implements a special interface (IAction) - it describes its appearance and behavior.
In the example, we consider the application from the previous article - the real estate agency.
The class header has XmlDoc comments, they have a dual purpose:
Firstly, this is a classic comment so that in the code it is clear what this action does.
secondly, this is the text (first line) and the hint (subsequent lines) of the button.
At first glance,
IAction - the interface of all system actions in order for the class to be a button; it must implement this interface.
Generic-parameter IItemContext is an action context; in this case, we need an entity element to position the button. So a button with this context may appear in:
RentOfferBase - indicates the entity (offers from the lessor) on which this button is available. Given the principle of inheritance , the button will be available for:
context - this is the context of the action that is in it:
ExceptionHelper.Interactive - Interactive Exceptions
ParameterManager.GetParameter - parameter request from the client (similar to interactive exceptions, but with the ability to enter data)
context.ShowNotification () - a way to interact with the client.
This button uses the IFormContext - the context of the form, unlike the context of the element, such buttons will not be accessible via the context menu, but they will be available when editing the form.
In this context, the context contains additional parameters, for example
context.FormData is not yet saved form data and additional methods that make sense only on the form, for example:
context.ChangeFieldValue (a => a.Price, averagePrice) - change field value (without saving)
In reality, several contexts are used, using the appropriate context allows you to position the button in the right place and get access to the necessary properties and call the appropriate methods.
For example, in the delete button:
In addition to the icon already known to us for it, we also indicate the following attributes:
We apply the same approach for the rest of the applied objects of the system.
Do you have examples of ERP (or other accounting) systems where you like the application code?
1C - a role model?
By application code is meant code that is directly related to the business logic of a particular application, while, unlike the kernel (framework, platform), such code is maximally subject to change and in large projects can be the lion's share of the project. The speed and quality of development in the most essential way depends on the convenience of the application developer.
For example, the Brainfuck Hello world language looks like this:
And here are our criteria for convenience:
- Strong static typing
- Documented
- Lack of “trash”
- Uniformity
- Conciseness
A typical example of an applied task is the development of a button with some action by pressing it. The button can be on the form , on the grid or in the system menu. Depending on the location, it has a set of available input parameters (what kind of form? What kind of grid? Which records are selected?) And a set of possible actions (update, change, open, etc.), we call their totality context.
')
In our system, to create a button, you need to develop a class of this button that implements a special interface (IAction) - it describes its appearance and behavior.
In the example, we consider the application from the previous article - the real estate agency.
Bookmark button
Comments
The class header has XmlDoc comments, they have a dual purpose:
Firstly, this is a classic comment so that in the code it is clear what this action does.
secondly, this is the text (first line) and the hint (subsequent lines) of the button.
Interface implementation
At first glance,
IAction<IItemContext<RentOfferBase>> may scare, but it's not so scary:IAction - the interface of all system actions in order for the class to be a button; it must implement this interface.
Generic-parameter IItemContext is an action context; in this case, we need an entity element to position the button. So a button with this context may appear in:
- Application form
- The context menu of the order list (right click on the item)
RentOfferBase - indicates the entity (offers from the lessor) on which this button is available. Given the principle of inheritance , the button will be available for:
- Offers from the landlord
- offers of rooms (descendant)
- offers of apartments (descendant)
Attribute
[Icon(ExtIcon.BookmarkAdd)] Indicates with which icon the button will be displayed.Method
public void Execute(IItemContext<RentOfferBase> context) Directly code executed by pressing a button.context - this is the context of the action that is in it:
ExceptionHelper.Interactive - Interactive Exceptions
ParameterManager.GetParameter - parameter request from the client (similar to interactive exceptions, but with the ability to enter data)
context.ShowNotification () - a way to interact with the client.
KNPOKA average price calculation
Attribute
[RequireRole(Role.Agent)] indicates that the user must have an Agent role for the button to be visible.Contexts
This button uses the IFormContext - the context of the form, unlike the context of the element, such buttons will not be accessible via the context menu, but they will be available when editing the form.
In this context, the context contains additional parameters, for example
context.FormData is not yet saved form data and additional methods that make sense only on the form, for example:
context.ChangeFieldValue (a => a.Price, averagePrice) - change field value (without saving)
More possibilities
Many contexts
In reality, several contexts are used, using the appropriate context allows you to position the button in the right place and get access to the necessary properties and call the appropriate methods.
Attributes too much
For example, in the delete button:
In addition to the icon already known to us for it, we also indicate the following attributes:
- confirmation with confirmation text
- selection requirements (no selection button is not available)
- hot key
Not just buttons
We apply the same approach for the rest of the applied objects of the system.
- Event entity
- Event Forms
- Login event
- Document operations
- Numbering tools
Subject for discussion
Do you have examples of ERP (or other accounting) systems where you like the application code?
1C - a role model?
Source: https://habr.com/ru/post/143566/
All Articles