Microsoft enterprise database 4.1 Study Notes (3) enterprise database migration and parallel use, and enterprise database expansion

I. Migration and concurrent use

Generally, the Enterprise Library is built on. NET 2.0, and later versions of the Enterprise Library do not need to be changed.Code. You do not need to update the reference to the newProgramYou do not need to specify the correct version of the Assembly in the configuration file.

The Enterprise Library of this version 4.1 can be installed with the Enterprise Library of the previous version. You can deploy the application that uses the new version and the old version together. You can also upgrade the existing enterprise database application to the new version at one time.

If you choose to use different enterprise libraries in parallel, you must deploy them in different folders. In any case, different versions of Enterprise Library assembly cannot be combined. For example, you cannot put the 4.0 data access-related Assembly and 3.0 caching-related assembly in a directory.

Assemblyinfo. CS under the application project has assembly information of different versions. In this way, you can use different versions of the Assembly in GAC in parallel by using a strong naming method.

1. Partial migration

Each assembly in an application can only reference one version of the Enterprise Library, but multiple assemblies can reference multiple versions of the Enterprise Library. For example, your application has two assemblies, which used to use the Enterprise Library 3.0. Now you can migrate one assembly to use 4.0 and retain another 3.0 reference. This means that you can gradually migrate and replace it once. Although step-by-step migration is supported, the implementation may be complex. Therefore, this approach is not recommended.

Note: The enterprise database configuration interface is customized according to the enterprise database version. Therefore, when configuring different enterprise databases, use the configuration programs that cannot be used below.

Ii. enterprise database extension Guide

Enterprise libraries can serve as the basis for custom class libraries. You can use the extension points of each function module to provide new support.

You can also modifySource codeTo form a new function. You can follow the following instructions when scaling.

You can expand the Enterprise Library in three ways. You can write a custom provider, modify the source code of the existing function module, and write a new function module. If you want to expand the Enterprise Library, you can refer to the following suggestions:

• Function modules should be exposed to facilitate developers to use them without modification.
• Function modules should be easily modified and expanded.
• The functional module should contain Microsoft patterns & Practices instructions
• The function module should contain some instruments
• Functional modules and other functional modules should be loosely coupled.

1. Method exposure

A function module should provide public APIs to expose its own methods, and the APIs should be independent of internal implementations. Developers should be able to use out-of-the-box functions provided by the module efficiently without understanding the design and implementation of the module.

At any time, APIs should provide general solutions for special features. Setting values on the configuration interface, rather than using code, may be useful for special situations and users, such as database names and the number of caches that can be used.

2. Extended and customized function modules

A function module should provide extensions to developers so that developers can crop function modules as needed. The most common extension is to allow developers to use their own providers. For example, a functional module for managing data stored in databases should allow developers to easily add different types of databases.

Developers should be able to extend the function module without modifying the source code of the function module. To achieve this, your extension points should include public base classes or interfaces. Developers can expand the base class or implementation interface, and then expand the function module by modifying the configuration file. In this way, you do not need to modify or re-compile the function module. Developers will find that the extended functional modules are very interesting, well organized, easy to understand, and should follow the guidance of Microsoft patters & practices.

When providing extensions, you also need to consider the impact on ease of use. A large number of extension points may bring great difficulties to the configuration and use of functional modules.

Some developers prefer custom code, which means they may modify the source code instead of using the extension point. To provide this function, the module design should provide the following guidance.

• In any actual situation, we should follow the object-oriented design principles.
• Correct use of design patterns
• Efficient resource use
• Security rules should be supported, such as untrusted user input and minimum priority.

The Code style and naming Rules should be consistent with the. NET class library. For details, refer to the design guidelines for class library developers of msdn. There is a code check tool called fxcop, which can check whether the code is consistent with Microsoft's class library design recommendations.

3. Including patterns & Practices

It is important to remember that the Enterprise Library is only a small part of Microsoft patterns & practices. A function module should contain instructions on patterns & practices.

4. includes performance meters

A function module should contain performance instruments so that developers, testers, and system administrators can monitor the operation behavior and performance of the function module. The number of instruments depends on the function module method. sufficient instruments are required to be provided to developers, testers, and administrators so that they can obtain sufficient information, ensure that the functional modules are running as they were designed, and the performance is within the acceptable range.

5. Loose coupling

If an enterprise library function module requires other modules to complete the work, the dependencies between them should be loosely coupled so that developers can replace them with their own implementations. If possible, use the plug-in model. Separate the code dependency of a provider. Developers can change to a different provider as needed.

Iii. enterprise database modification Guide

The Enterprise Library is designed to be usable in any application and provides common tool classes and methods. With the extension point, you can adjust the Enterprise Library to meet any special needs. However, if you want to add a new feature in the function module, you can modify the source code. In this case, you can refer to the following suggestions:

• By reading this document, you can understand how the functional modules of the enterprise database work.
• If you change the code signature or use a custom version while using the original version, you may want to modify the namespace. If you modify a namespace, You need to modify the namespace of all the relevant Assembly to make them consistent with the new namespace.
• Use strong names. Strong naming makes the Assembly have a unique identifier, version, and integrity check. You need your own signature to indicate the modified assembly.
• You must re-compile your code to check the impact of modifications. Develop Vs and recompile the entire solution.

Not complete ..................