Question "Everything is oo", the name of the database is re-positive-on ado.net Entity Framework

Http://www.cnblogs.com/tsoukw/archive/2008/09/11/1288942.html

Since the advent of Java, C #, and other languages, OO has become a great honor. For a while, "the motherland has a vast variety of O ".

I have to say that the idea of OO is indeed a fresh sensation compared with the previous software design methods. However, I am afraid it is worth discussing. At least in business application or oriented-data application, oo cannot replace the database (relational database) defines and stores the core business logic in the business system. Compared with procedural VBScript, the OO language can only encapsulate some functions at most. However, in terms of abstraction, reuse, and change, OO has won the system designer's simplicity and perfection in solving these problems. favor, that is, at that time, I forgot another database in the business system that played a completely different role from the procedural language.
The "database is dead", "Oo and database have a natural impedance", "object will replace the Database" and other comments will fly in the sky, and there will be no "Database" at a time, and I will never give up.. It is ridiculous that although there is such a "straightforward" slogan, oo still cannot leave the database. In order to conceal their embarrassing situation, they had to create another o/R Mapping and claim: OO IN THE SYSTEM objects can be converted into relationships through Orm, but stored in the database, the database is only a persistent method in my system, so that my oo can be "Revived" again, in addition, do not have it yiyun cloud.

Let's take a look at how Oo, which has separated the database and exists independently, represents "business logic? First, we need to design the object and extract the domain model (various naming methods, casually). Although OO has its distinctive features and rich means to encapsulate and abstract it to respond to changes. However, there is no way to describe the relationship between objects in OO. It can only be described simply by attributes. No standard result is free design and self-comfort: This is Oo, because Oo is a simulated reality. You can see how convenient it is when I add an attribute, just a few lines of code.. It can be seen that the relationship between Oo is a kind of mesh relationship. In terms of the data structure, it is a graph (rather complex than the set theory of the database Relationship Model ). However, freedom means the cost, because objects in OO need to be persistent, unless the CPU can directly access the hard disk or the data can continue to exist after power loss. OO still has to rely on the database to help it persist (do not mention the object database, unless there is a new theory, the object database should be a kind of mesh database, and facts have proved that the relational database is concise in description ﹐ query convenience and performance advantages are superior to those of the mesh database) therefore, Oo must be converted to a relational model and stored in the database.
Mapping also follows.

Why? This is the same thing. Why is it so troublesome. The most common example is that the order system may have two objects: the order and the customer. to indicate who the order is, an attribute is added to the order object: The order owner. In some cases, you may need to know which customer has placed the order. Therefore, the "Order List" attribute is added to the customer class to indicate the order placed by the customer. We can see that OO indicates the complex relationship between objects. The same link must be described twice or multiple times. The relational model of the database is much simpler: entity: Order, Customer Relationship: Order (Order Number, customer ID) you need to know the order owner, through the "order" relationship, the customer's order, and through the "order" relationship. Undoubtedly, the relational model is concise and effective in describing the relationship between entities (or objects.
This is the relational model of the great database, which is similar to the "free" mesh model of the object. How to solve the mismatch between the relationship and the object is actually very simple. The relationship model theory is used to guide the "object" design. For example, three objects (two entities and one relationship) need to be designed in the preceding example: orders and customers, and orders (representing the relationship between orders and customers) an order object has the following attributes (the order owner and the order attributes, and their attribute types are naturally two objects ).

/// <Summary> /// product /// </Summary> class product {public string name; // product name public decimal price; // unit price} // <summary> // order /// </Summary> class order {Public String no; // Order Number public datetime date; // order date Public Product product; // product public int quantity; // quantity public decimal amount {get {return product. price * quantity;} // amount} // <summary> // customer // </Summary> Class Customer {public string name; // name Public String address; // Address Public String email; // email} // <summary> // order relation // </Summary> class ordercustomerrelation {order; // order customer; // orderer} // <summary> // order relation set // </Summary> class ordercustomerrellist {public static ordercustomerrellist instance {get {return New ordercustomerrellist ();} // complete instance capturing} public list <ordercustomerrelation> lists ;}

Describe the customer of the order through the "place order" object. For convenience, you can add a "get customer" method in the order class, which is implemented through the "order" object set. The "Order List" attribute you added to the customer class is also completed by querying the "order" object set.

/// <Summary> /// order /// </Summary> class order {Public String no; // Order Number public datetime date; // order date Public Product product; // product public int quantity; // Number of public decimal amount {get {return product. price * quantity;} // amount public customer {get {ordercustomerrellist list = ordercustomerrellist. instance; foreach (ordercustomerrelation rel in list. lists) {If (Rel. order. equals (this) return customer;} return NULL; // cooler query expression implementation // return list. lists. first (rel => Rel. order. equals (this )). customer ;}}/// <summary> // customer /// </Summary> Class Customer {public string name; // name Public String address; // address: Public String email; // email /// <summary> /// actual, you should design a class encapsulation list <order> so that the add and remove methods can add and delete relation /// of course, you can decide to complete the order logic in the set_customer of order according to actual needs, so there is no need to complete the order logic in the orders of this class. // </Summary> public list <order> orders {get {list <order> ret = new list <order> (); ordercustomerrellist list = ordercustomerrellist. instance; foreach (ordercustomerrelation rel in list. lists) {If (Rel. customer. equals (this) ret. add (Rel. order);} return ret; // a cooler LINQ implementation // var TMP = from rel in list. lists where Rel. customer. equals (this) Select Rel. order; // return TMP. tolist <order> ();}}}

Maybe it's not natural to design the relationship that you think the client needs to operate on. In fact, it doesn't matter. You just need to make a layer of encapsulation: let the "customer" attribute of the Order class be set, create a "link" in the set.

/// <Summary> /// order /// </Summary> class order {Public String no; // Order Number public datetime date; // order date Public Product product; // product public int quantity; // Number of public decimal amount {get {return product. price * quantity;} // amount public customer {get {ordercustomerrellist list = ordercustomerrellist. instance; foreach (ordercustomerrelation rel in list. lists) {If (Rel. order. equals (this )) Return customer;} return NULL; // cooler query expression implementation // return list. lists. first (rel => Rel. order. equals (this )). customer;} set {ordercustomerrellist list = ordercustomerrellist. instance; var relation = List. lists. first (rel => Rel. order. equals (this); If (relation! = NULL) relation. customer = value; else {Relation = new ordercustomerrelation (); relation. customer = value; relation. order = This; List. lists. add (relation );}}}}

Further, you can design an O/R Mapping Framework. You can also select an existing ORM scheme to implement the full correspondence between objects and entities, relations and relationships, and finally completely "oo". net 3.5 SP1 is released. This framework MS has helped you implement it. This is the ado.net Entity Framework ﹕) my Opinion on Entity Framework: Although at first glance, it seems to be an O/R Mapping, but unlike the previous Orm, it puts forward a theory the relational model is used to design objects and then perform mapping. This is a step further than other ORM with only tools and no idea. As for its E
SQL and LINQ to entity allow you to operate on this ORM as you like ~ "This is the same root, it's so urgent to be confused." Oo and the database share different roles and responsibilities like human facial features. Oo is responsible for designing system architectures, business processes, implementing abstraction, and encapsulating changes.. Databases are responsible for the presentation, storage, and query of business logic. The relational model is used to build an effective bridge between Oo and the database. And for expensive ﹗