Behind datarabbit (1)-enter the context of datarabbit

A concept can be clearly and clearly defined only when it is put into a specific context. Without context, the concept loses its value and vitality. Therefore, when learning to use any technology or concept, one thing is very important, that is, to thoroughly understand the context in which the concept is located, this will help us better use and control this technology.
Today, with the popularity of ORM, data access frameworks are emerging one after another, but the contexts of these frameworks are almost different. To use a data access framework well, you must understand the context of the framework. Similarly, if you want to exert the power of the datarabbit framework, you must understand the context of datarbbit before.

I. Pure Orm?
During the development of datarabbit, I made a very important decision: datarabbit cannot be positioned as a pure ORM framework, that is, all data access functions are implemented based on Orm. The reason is very simple. Orm cannot do everything (even if everything can be done, it will take a huge cost). Some databases still need to be accessed based on relationships, I think it is unwise to make decisions on pure ORM frameworks that do not provide relational-based data access operations. Therefore, in datarabbit, Orm-based data access and relational data access account for half of the sky, which makes it impossible for us to achieve it Using ORM or it is difficult to use Orm, you can turn to the relational accessors.
In addition to the core ORM accessors and relational accessors, datarabbit also provides the ability to access and operate the "outline" of a data table, this is because we often have the following requirements: to obtain information about a field in a data table, to find a primary-foreign key relationship, or to dynamically create a data table with a specified outline. Currently, the outline operations provided by datarabbit are relatively thin and will be gradually enhanced in the future.

2. core concepts in datarabbit
1. lightweight and weak intrusion. For example, datarabbit does not have any requirements for your database design (and some data access frameworks may require that the data table must have a unique primary key ).
2. Conventions are better than configurations. Datarabbit does not require any configuration, making it easier to use.
3. Database Type independence. The unified data access interface shields the differences in database types. Currently, datarabbit supports sqlserver and Oracle, and supports other types of databases through plug-ins.
4. All data access functions in datarabbit are provided by various accessors (such as iormaccesser, irelationaccesser, itableaccesser, idataschemaaccesser, ientityrelationloader, and ispaccesser.
5. all accessors can be referenced from the datarabbit root ("root"). In datarabbit, there are two such roots: the idataaccesser interface and the transactionscope interface.
6. A root instance corresponds to a database. We can also say that for a specific database, our application only needs to maintain a datarabbit root.
7. All accessors (such as iormaccesser) provided by datarabbit can work in two environments: transaction environment and non-transaction environment. This is reflected by the itransactionaccesser interface inherited by All accessors.
8. if any accessors instance works in a non-transaction environment, it is stateless, and datarabbit will provide its instances in singleton mode; if the accessor instance is in the transaction environment, it is stateful and its life cycle ends with the end of the transaction, datarabbit provides its instances in single call mode.

3. orm concept in datarabbit
The ORM concept adopted by datarabbit is simple and simple. Its main features are as follows:
1. orm only operates on a single table and does not support multi-table joint access. I have no good idea about the ORM solution for multi-table joint access.
2. A table in the database corresponds to an entity class definition, which is a one-to-one ing relationship.
(1) To save unnecessary trouble, the Class Name of entity class should be exactly the same as the name of the corresponding table. In this way, datarabbit can easily find the corresponding table in the database based on the name of the entity class, or vice versa.
(2) each column in the table corresponds to an attribute in the Entity class. The column and attribute names must be identical and their types match.
(3) a record in the table corresponds to an entity object.
3. ORM Data Access operations are defined not in Entity class, but in specialized ORM accesser. In this sense, entity class is more like a structure that only encapsulates data, rather than a class.
4. Orm accessors Adopt generic and reflection technologies. In this way, datarabbit only needs to provide an ORM accesser class to access all tables in the database.
5. The ORM accessors use generic parameters to indicate which table to access. Another benefit of generic parameters is that all ORM access operations are strongly typed.
6. Use filter to represent a single query condition. An important purpose of ORM is to block all SQL statements. Therefore, SQL condition clauses need to be abstracted.
7. Use the ifiltertree interface to abstract the combination of complex query conditions.

4. datarabbit provides support for the n-layer architecture.
datarabbit is designed and implemented, we have considered how to better support the system architecture. Therefore, datarabbit can be smoothly and seamlessly integrated into the Layer 3/n architecture. For details about this, see: datarabbit lightweight data access framework (12)-integrate datarabbit into the architecture