ORM Component xcode ()

 

Previously, xcode was always vague, and students with good patience wanted to know what other features it had. Those who couldn't help but thought it was just curd ears!

The xcode development mode is the soul, and the xcode component supports it through specific implementation!

Xcode has the following features:

0. Basic curd Functions

It is hard to figure out that An ORM that does not support curd is not an Orm. It is also hard to figure out that An ORM that only supports curd is not an Orm. Therefore, this is the 0 function!

Xcode curd generates query and operation SQL statements by reflecting the object class. The database structure information is attached to the object class through features. SQL rather than dbcommand is selected because xcode's entity layer and data access layer are separated. Currently, it is used to implement a level-1 cache and distributed data access will be implemented here in the future.

1. Full support for objectdatasource

Xcode implements the object class of the congestion model (bloat blood model) and provides all the methods and parameters required by objectdatasource, especially the paging and sorting functions!

For details, see dancing with objectdatasource.

2. Comprehensive paging support

Only by cultivating the idea of paging from a small point of time and specifying the data range to be obtained for any query can the system not expand when the system data increases.

Xcode paging is based on any query statement and supports complex query pages such as statistics. The best paging scheme is selected based on the current database type and version.

For details, see leverage tens of millions of data records.

3. entity set support

Entity List <tentity> inherited from list <tentity> provides entity batch operations. In fact, we still perform entity Operations one by traversing the set. Because the entity class of the congestion model may modify the curd behavior through overloading, we cannot use an SQL statement to operate a batch of entities, xcode will not do this trick that may affect usage.

Entity sets also provide some simple methods to facilitate query and sorting. entity cache will be used in large quantities.

4. omnipotent level-1 Cache

A level-1 cache is implemented by the data access layer. It uses the query SQL as the key, the returned data set as the value, and the queried table name array as the dependent item for caching. When executing SQL statements, you also need to specify an array of affected table names to clear all affected caches.

The cache lifecycle is divided into three types: Request-level, periodic, and permanent. If the database is used only by the current application system and the server memory is large enough, you can enable permanent cache. when data is not updated, the database is basically cached in the memory, which is applicable to websites; generally, you can set a cache expiration time and regularly clear the cache. This applies to distributed systems that are not very adequate in memory or allow data updates to be delayed. If either of the above two methods is inappropriate, in addition, when the system response speed needs to be improved, the request-level cache can be used to cache data during the page request lifecycle, it is especially suitable for performing the same query in different places (sometimesProgramThe employee's skill is not enough to write a mistake ).

In xcode development mode, we recommend that you use single-table queries as simple as possible. Most queries are simple SQL statements, and the cache hit rate is very high!

5. Beautiful entity Cache

The entity cache becomes a second-level cache. Although a level-1 cache is available, it only caches the dataset. When using it, you still need to load the dataset to become an object set.

The object cache specifies a method to query object sets. It generally queries the findall () method of all objects in the table and caches the object sets returned by the query (one minute by default) for the upper layerCode. The process of data retrieval is completely implicit. The entity cache provides a static entity set for upper-Layer Code query, and the entity set attributes perform data query and cache expiration check internally. The query method is passed through delegation. You can also specify whether to asynchronously obtain cached data.

In short, using the object cache is to use a static object set attribute (default configuration is used most of the time, so no configuration is required) for query sorting and other operations, without the need to care about the specific implementation of the cache. Of course, when you modify an object, the cache is cleared to ensure data freshness.

The data volume of a single table is small (less than 1000 is recommended, but not more than 10000), and data tables that are rarely modified are cached using entities. For example, permissions, roles, menus, system parameters, and other frequently used data. The hit rate of entity cache can reach 99.98%.

6. Elegant single-object Cache

A single object cache is a layer-3 cache because it is generally built on a level-2 cache. For data tables with a large data volume (about tens of thousands to hundreds of thousands) and frequently queried data tables, you can use a single object cache as appropriate when there is little relationship between any two rows of data. For example, the member table is usually searched based on the account, and frequently used. In this case, the account can be used as the key and the member object is used as the value to cache the data. The setting is similar to the object cache. When data is retrieved, it is first searched in the cache. If yes, it is directly returned. If no, the preset method is called for query and cached.

When modifying data, do not manually call the update method for entity objects in a single object cache. A single object cache can be automatically saved. This feature is suitable for scenarios where updates are very frequent. For example, online user tables can accumulate multiple updates, and then automatically update them.

7. Excellent Performance

Xcode does not support multi-table queries. Generally, multi-table join queries can be split into 1 + x Multiple Single-table queries. For example, you can query the association between students and classes by checking the information of 10 students first and then querying their class information separately. Then, you can query the table for 1 + 10 = 11 times. Each single table query is certainly faster than a multi-table join query, but 11 single table queries are often slower than a single multi-table join query.

Looking back, looking at the cache above, if the 10 students are in the same class, the actual query database will be 1 + 1 = 2 under the first-level cache, the last nine class queries were intercepted by the level-1 cache. In high-concurrency systems, the next 1 tends to be 0, because the cache is shared globally.

Let's look at the Entity cache. There are not many classes in a school. The entity cache is used to meet the conditions. That is, all class information is read at one time and cached to the object set. Even in the worst case, 10 students are in different classes, and the entity cache is hit. The actual query is only a single table query for the student table, this is certainly faster than multi-table join queries.

Student table queries are frequently performed on student information interfaces. Obviously, this is a very suitable scenario for single entity caching. Student affiliated attributes (associated tables) and other information can be expanded to "Hung" on the student object and "enjoy" the cached treatment.

There is also a cache at the database level, which can be regarded as level 0 cache. All our queries are single-table queries, which are very simple for the database. At the same time, because of simple SQL statements, the database cache hit rate is extremely high and it is very easy to create indexes for optimization.

Based on paging and caching, xcode provides a high-performance solution. This solution is far better than traditional multi-table join queries, and the higher the system concurrency, the more obvious this advantage.

8. Dirty data support

When updating data, we often need to update only the modified data. For example, you can set member information and other materials to modify the form of member data, but you cannot modify the Last Logon Time. At this time, we need to know which attribute of the data has been modified!

In xcode's object class, the onpropertychange method is called for the Set Method of each data attribute first. In fact, it is used to set the dirty attribute of this field, indicating that the data of this field has been modified. When an update statement is generated, only the fields with dirty attributes are modified.

In Entity classes, you can modify attributes in addition to directly modifying attributes by using the indexer. The difference between the two is that when you modify attributes by using the indexer, dirty data settings are not affected. In fact, the index is used to load the data row to the object class. Therefore, when the data is loaded, the dirty data is empty.

9. Multi-Database Support

(Mssql2000, mssql2005/2008, Oracle, MySQL, access, SQLite)

Like most Orm, xcode supports multiple databases through interfaces. In xcode, a database operation class is implemented for each database, inherited from the database interface. The data access layer Dal identifies a database based on the database connection configuration, creates an instance of the database operation class, and operates the database through the operation interface.

The database operation class is modeled on the Access database and a base class is designed. The operation classes of other databases only need to inherit this class. The properties and methods of the Operation classes with different feature points are greatly reduced.

Database Operation interfaces include query, execution, paging, transactions, architecture retrieval, DDL operations, and database versions. In fact, the differences between databases can be designed in the operation interface, and the upper-Layer Code does not need to be modified.

Many ORM systems are worried about the differences between different databases, while xcode development mode is not. Our principle is that everything is simplified, only SQL is used, and dbcommand and stored procedure are not applicable. The SQL statement used is basically a standard SQL statement. It does not use database features and is operated on a single table. Of course, this method is not omnipotent. You can determine the current database type at the business layer and write different SQL statements based on different databases. However, since xcode was used, this is not required yet.

10. Obtain the database architecture

(DAL. Tables)

In xcode, the database architecture mainly includes xtable and xfield classes. As the name suggests, they represent table and field information. The data access layer Dal has a member attribute tables to obtain information about all tables connected to the database, that is, an xtable set. Similarly, each xtable contains an xfield set.

This design is simple and clear, and users can easily find what they need. Our code generator xcoder relies on xcode to obtain the database architecture. With this function, everyone can write their own code generator!

11. Reverse generation of database architecture

(Databaseschema)

This is a very different feature and seldom comes with Orm. During the development and maintenance process, it is inevitable that you need to modify the table structure and regenerate the entity class (only the entity class data file part is generated ). During team development, if the database is not shared, the team members must be notified to make corresponding changes. During maintenance, you also need to update the production environment. if the customer does not allow direct operations on the database, it is more troublesome.

In the database operation interface, one function is DDL operations. After each database is overloaded, you can use DDL statements to operate the database structure. Common functions include creating tables, modifying field attributes, adding fields, and deleting fields.

In addition to generating the database architecture from the database, xcode also generates a set of database architecture from the entity class, and then compares it. If there is a difference, it directly modifies or writes a log reminder (determined by the settings ). When the modification switch is not turned on, only the log reminder is written. The complete DDL statement used to modify the database architecture is written in the log and can be executed in the database.

A system developed based on xcode never carries a database when it is released, because xcode automatically creates databases, data tables, and fields based on the connection string. Even if database a is used for development, when the database connection string is changed to database B during release, xcode will create a database according to database B specifications. If the system requires additional data for release, it is impossible to change the database during the release, unless multiple database versions are released.

Some people may say what to do if the database is not included in the initialization data? In xcode's development philosophy, we recommend that you add a static constructor to the object class to detect data in a data table. If no data exists, do you need to create a default data, for example, you can create an admin user name and password in the administrator table.

12. dynamically modify the connection and table name

(Meta. connname, Meta. tablename)

When the data volume increases to a certain extent, many enterprise solutions are to change the name of a data table or migrate the table to another database for query statistics only.

In xcode, when an object class is generated, the table name corresponding to the object class is specified, but we do not need to generate multiple object classes for multiple tables with the same table structure, because the object class can dynamically modify the table name to which it points, the target table of the operation is changed. To avoid the impact of the multi-threaded environment, this modification only affects the current thread.

The connection name is modified in the same way as the table name.

13. Weak access

(Ientity, ientityoperate)

Sometimes, we don't know which entity class to operate on. We can determine it only at runtime. A common practice is reflection!

In order to avoid unnecessary performance losses and to avoid unsightly coding design methods, xcode provides the ability to access weak types. You can find the object class by specifying the type or table name, and create an ientityoperate operation object to complete various operations on the object class.

The methods provided by ientityoperate are basically the same as the static methods of the object class, so they will not encounter any difficulties in use. Ientityoperate returns an ientity set for data query, because each entity class implements the ientity interface, which is sufficient to complete basic curd operations.

14. dynamically generate code

(Codedom, memory entity)

With the support of weak type access, some simple database operations do not necessarily need to generate entity classes. When xcode cannot find the entity classes, it will generate an entity class in the memory according to the table architecture, then compile and use.

Another goal of dynamic generation is to allow users to generate entity-class code by calling some methods, rather than generating it through xcoder.

15. Extended Loading

(MAP fields in the query to extended attributes)

Xcode supports the congestion model. From the object-oriented perspective, all the features (attributes) and capabilities (methods) of this object should be implemented on the object class. In addition to the basic data attributes corresponding to database fields, there are also some attributes associated with other object objects, which are called extended attributes. For example: article. Board. Manager. username, you can directly get the User Name of the moderator of a post.

Xcode does not support multi-table join queries, but it has extended attributes. All multi-table join queries can be encoded using extended attributes. The board extension attribute in article is loaded only when it is used. In addition, the Board can use the entity cache, which basically has no database operations. The manager cannot use the entity cache, But it "hangs" on the Board as an extension property and indirectly "enjoys" the cache.

You can also compile a common attribute as an extension attribute. When you perform a query, the data is mapped to the extension attribute through the selects parameter. For example, add an integer attribute of total and execute the query article. findall ("boardid = 123", null, "Count (*) as total", 123), this query gets the number of all posts with the topic number, then, the results are mapped to the total attribute. The returned record set has only one entity object. The total attribute of this entity object is the number of posts to be queried. At this time, other attributes have no significance.

This function is generally used in query statistics. It is much easier to use an object to represent data than a dataset.

The extension attribute is unique to the congestion model and the biggest advantage over the anemia model (including the blood loss model!

16. Generic base class model

(Entity <tentity>)

Xcode has entered the second generation since v1.2. The key point is the use of the generic base entity <tentity>.

In the first generation of xcode, because of the congestion model, Entity classes must be accompanied by a large number of methods. When their return types are Entity classes or object classes, these methods must be implemented in the code of the entity class, which is actually generated by the code generator.

In the second generation of xcode, the generic base class technology is introduced. The entity class uses the generic parameter tentity to specify the final return type. When writing a query method, the generic parameter tentity is used for the return type. Therefore, the second-generation object classes only have attributes and indexers, and do not need to generate query and operation methods, because they are all implemented in the generic base classes.

In most cases, the base class generic parameter specified by the object class is its own, because it needs to use its own as the return type. However, the xcode development mode is object-oriented, including entity classes. It also hopes to inherit and add some features, which can be implemented by changing generic parameters.

17. object class inheritance and overloading

(Newlife. commonentity)

By changing the specific type of generic parameters, You can inherit and overload object classes, marking the third generation of xcode. It indicates that we can encapsulate some basic data entities for multiple projects.

Newlife. commonentity is a common entity component that encapsulates entity classes such as region, Administrator, role, menu, and authorization. Specific projects can be used directly or extended through inheritance and overloading.

Taking the encapsulated region table as an example, it detects the number of data tables in the static constructor. Of course, xcode will automatically detect and create the region table before that. If no data exists in the region table, a method is called to initialize the data. The region table service code is hardcoded and has a built-in region code and name for thousands of regions in China. Once the country changes the region division, you only need to modify this class. All projects that use this component will use the new region data. If the code of these functions is copied to every project in use, it will become very difficult to maintain.