Processes and functions
In order to highlight their own advantages, database manufacturers have provided rich and personalized processes and functions.
In order to improve product scalability and data irrelevance, please do not use procedures and functions related to specific databases, and it is not recommended to use Store Procedure. It is recommended to use the middle-tier business objects of the application server.
Field/domain definition
Try to avoid using blobs. If you must use it, please do not index blobs and do not define multiple blobs.
Do not use the date field, instead use the string char(19), such as: 2008-12-09 12:22:08.
For strings that determine length, fix the length of the field type, such as char(80), and do not use varchar.
For the value type field, use the corresponding database value type instead of strings.
3. Com and .Net interoperability specifications
.NET technology has become the mainstream of Microsoft platform, but in the Win32 era, many COM and DCOM components were developed. Since a lot of manpower and financial resources were invested in developing COM components, it is more meaningful to reuse these COM components in the .NET environment.
.NET supports two-way interoperability between COM, COM+, local WinAPI calls and unmanaged code at runtime. To achieve interoperability, the namespace of the .NET Framework must be first introduced.
The syntax of C# is:
| using ; |
1) .NET access API
.NET allows C# to access functions that are unmanaged DLLs. To call the MessageBox function of Windows:
int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType)
You can declare a static extern method with the DLLImport property:
| using ； [DllImport(“”)] static ertern int MessageBox(int hwnd,string text,string caption,int type); |
Then just call it directly in the code. Here we should pay attention to using the StringBuilder object in the API that calls the return string.
2) .NET access to COM components
Calling COM components from .NET is easier, just use WarpClass that produces COM and then call it in the .NET project.
Note that the COM type information is described by the Type Library file, and the .NET assembly is self-described. The function of Tlbimp is to generate self-described assembly from COM components and their type information.
1. Writing Com Components
Compile to generate one.
2. Generate .NET accessibility packaging classes (assembly) and use .NET assembly to generate.
TlbImp /out：
3. Access in .NET code
.NET code can access COM components just by reference.
4. Exception handling
Principles of exception handling
Handle all general exceptions in the application-level (thread-level) error handler. When encountering an "unexpected general error", the error handler should catch the exception and prompt the user for a message, and record the error message before the application is closed or the user selects "Ignore and Continue".
It is not necessary to use try-catch for each method, only when a specific exception may occur. For example, when writing a file, exception FileIOException is handled.
Don't write too large try-catch module. If necessary, write a separate try-catch module for each executed task. This will help find out which piece of code produces an exception and send a specific error message to the user.
If the application requires it, you can write your own exception class. Custom exceptions should not be derived from the base class SystemException, but should be inherited from IApplicationException.
During the development phase, it is not necessary to catch general exceptions in all methods. Deliberate indulgence exceptions will help find most errors during the development cycle.
Tips for exception handling
Don't catch exceptions and do nothing, it seems that the system is running normally. If an exception is hidden like this, you will never know whether or not or why it happened.
When an exception occurs, give a friendly message to the user. But you must accurately record all possible details of the error, including the time of occurrence, and related methods, class names, etc.
Never use error prompt messages like "Application error occurred" or "An error was found", but should give specific messages like "Update the database failed, please make sure the login id and password are correct."
When an error message is displayed, the user should also be prompted to resolve the problem. For example: "Updating the database failed, please make sure the login id and password are correct." instead of just saying "Updating the database failed".
The messages displayed to the user should be short and friendly. But all possible information should be recorded to help diagnose the problem.
Code examples for exception handling
The following exception handling mode is recommended:
| void ReadFromFile ( string fileName ) { try { // Read the file. } catch (FileIOException ex) { // Record exception logs // Re-sell targeted exception information throw; } } |
The following exception handling mode is not recommended:
| void ReadFromFile ( string fileName ) { try { // Read the file } catch (Exception ex) { // Catching general exceptions will never know whether it is a file error or other error // Hiding exceptions will never know that an error has occurred. return ""; } } |
5. Application and release of object instances
The garbage collection mechanism of the .Net platform can automatically dispose object instances that are no longer referenced, so many developers do not actively release the object resources they are applying for. In fact, it will not be released until the end of the life cycle of the object.
However, many times when the object is within its life cycle, we no longer use it in order to free up resources and improve system efficiency. Therefore, it is necessary to actively release the applied resources.
Never give the operating system what you can to it. It is a good habit to release resources that you no longer use in a timely manner.
6. Database access
Database access is always a bottleneck in the system, and choosing an efficient and robust database access model is the basic guarantee of product performance.
Never assume that your application system is built on top of a certain database, so there must be a unified and transparent database access mechanism.
Use access to the database
Based on the consideration of efficiency and stability, the database access model native to the Microsoft platform is adopted. You can access the database through OLEDB and ODBC modes. We recommend using the OLEDB mode provided by the database manufacturer. This mode bypasses ODBC, greatly improving the cursor performance of the database and improving efficiency.
Not using third-party data persistence layer. Using third-party data persistence layer tools like Nhibernate can improve development efficiency, but reduce system performance and elasticity. Performance is much more important than development efficiency for products, and efficiency is not a problem based on VS2005 development. Please remember: third-party tools can never become the core technology of your product; data access mechanism is the efficiency bottleneck of the system, yes
Data objects that use independent property rights
Directly adopt the lowest-level data access method of encapsulation: insertion, deletion and update, and transaction management, etc.; the client and server adopt the same data access mechanism, and set up a connection buffer pool to improve data access efficiency.
7. Distributed transaction management
For multi-layer distributed applications, database transactions show the characteristics of "remote and distributed", which makes transactions difficult to manage.
For example, transactions bind database connections, so each database connection must be managed in the data access object. If you want to access the database, the data access object on the server will automatically assign a specific connection to perform data operations based on the connection ID; no matter how many remote client processes the transaction is distributed to, the server data object only needs to lock the connection ID to easily manage transactions.
8. Smart client
Smart Client is an easy-to-deploy and manageable client application that combines the advantages of thin and fat clients, providing a fast responsive and rich interactive experience by coordinating the use of local resources and intelligent connections to distributed data resources.
Smart clients are divided into three types: Windows Form, Office Client, and Mobile Client, with the following characteristics:
Utilize local resources
Utilize network resources
Supports occasional connections
Provides smart installation and updates
Provide client device flexibility
The .NET framework base library embeds rich assemblies that support smart clients. By using the Common Language Runtime (CLR), you can use any language supported by .NET to develop smart clients.
Smart clients are a powerful alternative to thin client segments and are also a client model recommended by Microsoft. Try to use smart clients instead of browsers. If possible, please build your client system on an Office platform, such as Outlook.