Whether the business model can be completely abstracted from a single storage layer from the use of EF

In the last rush of time, I wrote a practical application mode for EF in the previous project. Because it was too long, I failed to discuss too much, so I continued to expand.

What I want to discuss this time is,Entity. If it is a business model similar to a domain model, can its data come from different data sources?. This idea comes first from the application where model first + code is supplemented to produce an excellent effect. On the one hand, it satisfies the paradigm and reduces the data storage capacity; on the other hand, it uses the encapsulation feature to provide a business entity that meets the business expectations.

 

First, let's look at an example.

I used model first to create an account entity. The actual generated code is as follows:

public partial class Account{    public int Id { get; set; }    public string FirstName { get; set; }    public string LastName { get; set; }}

Correspondingly, the above three fields correspond to the three fields in the database respectively.

Then, I use the partial class method to expand the account:

public partial class Account{    public string FullName    {
        get
        {　　        if (this._fullName == null)   　　     {      　　      this._fullName = String.Format("{0} {1}", this.FirstName, this.LastName);　　        }   　　     return this._fullName;
        }    } string _fullName;}

　　

Here is the key.At this time, what the business logic calls the account is no longer a simple Dao object, but a business model object with four business fields. If you are interested, you can refer to the section of the intermediate design pattern in my previous article "Entity Framework and object-oriented, this section describes the object-oriented design methods for entity applications, such as inheritance, polymorphism, and encapsulation, to achieve the effects required by the business model.

 

My questions

This method adds the complete object-oriented feature for entity has an idea that whether an entity can be completely abstracted over the storage layer and allow the data of an entity to come from different data sources.

 

First, from the perspective of the storage layer, the three fields ID, firstname, and lastname of the account in the example are from the relational database, and fullname is from the computing value, that is, the memory. From the database perspective, fullname is indeed not in line with the paradigm, so it is "redundant ".

For the time series, the data of the first three database fields has been loaded while the fullname is lazy load.

However, for the business, what he obtains is only an instance of an account containing four fields.

 

　　So my problem continues to expand. Can a business model completely encapsulate the data source and completely remove the focus when the business obtains the entity?

　　

When I get a product, the basic attributes of this product come from relational databases. The product introduction comes from nosql and the statistical value comes from dynamic computing.It is important that this is an object instead of assembling multiple objects..

 

In fact, it is encapsulation.

In fact, it is clear that this is a encapsulation problem. What we used to encounter was the impedance mismatch between relational databases and object-oriented databases, which was then Solved With Orm. Today, we may also encounter mixed use of non-strong objects and non-relational databases, as well as strong objects and relational databases, which makes it the norm.

Generally, we need to select a type in technology for the sake of a feature. Either static or dynamic. However, when another method is more appropriate, the implementation becomes awkward.

For example, if the above product is used, how many people put the product details as the entire text value in a field? How many people are using a table to solve the problem of dynamic fields?

 

Implementation, reality?

In the account example, this behavior is easy to implement. On the one hand, it relies on EF to provide relevant support, on the other hand, it isThe two storage sources have time-based associations.. During a business, all databases, that is, the data stored in the persistent storage, must be read to the memory before being operated. In this vertical relationship, data sources in the memory are embedded into the entire business process.

However, when the two data sources do not have a vertical relationship but a parallel relationship, the problem arises. This is similar to the impedance mismatch in the current year.

 

The first is an iteration problem.

As we all know, Data Retrieval costs. Data is "obtained" at the Abstraction Level and "copied" at the implementation level. The copy process includes "transmission ". Copying and transmission are the cost of data acquisition, which can be greatly amplified in some situations, such as the previous recursive query.

If you do not write SQL statements recursively, You need to obtain data from the database many times at the business level. The business results are the same, but the performance results are significantly different.

The hypothetical behavior of getting data is as follows:

 

When there are two data sources, there will be a "data convergence" problem,It is actually a synchronization and matching problem..

The data obtained from the two data sources needs to be matched, and it becomes very troublesome in a large number of queries. Isn't it easy to match in order? But you need to know that "order" is a very strange proposition. The data you find is a set or a list that only has "order". For key-value forms such as nosql, how to define the order?

In addition,If one data source is required to forcibly cooperate with another data source, the efficiency of one data acquisition is determined by the slowest data source..

I want to try again, if all or part of the loading is delayed, then whether it is necessary to read data asynchronously and merge the data, A thread is required to merge data.

 

I plan to try

I am happy to give it a try.

The idea at the beginning is to first try to extend the field and encapsulate the data source. Then, I should try to cut into the LINQ provider to see if it can be used in LINQ. net Usage may be more important.

Whether the business model can be completely abstracted from a single storage layer from the use of EF