Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Although I tend to agree with Tim about the "religious" element of framework choices, I still find it a bit odd that so many people are willing to comment on the EF when they so clearly haven't bothered to learn how it works. The EF, it turns out, would be a lousy version of NHibernate, just as hammers make poor screwdrivers. It is important to understand the EF on its own terms.</p> <p>Before I address some of the points raised in comments here, I'll add that we have just shipped version 2 of a production web app with 0 lines of SQL and 100% of all DB access done through either the EF or the ASP.NET membership API to our clients. I speak here with real-world experience with using the EF, something which, regretfully, is clearly not true of the authors of most of the comments on the EF I've seen thus far.</p> <p>In general, I think it's a mistake to extend your entity types. That the author of the blog post Tim cited (1) wasn't aware it was possible and (2) thinks this is the route to implement DDD tells me all I need to know about his real-world EF experience: <em>He hasn't got any.</em></p> <p>POCO support became a very big deal to users of certain ORMs because they didn't have a functional LINQ implementation for many years. Since you were essentially stuck with whatever type objects came out of the black box, having control over the parent type became a very big deal. So big, in fact, that writing your "POCOs" with <em>every member</em> declared <code>public virtual</code> began to be seen as no big deal. On which planet is this a "plain" type? It's a proxy base, not a POCO. The so-called "POCOs" aren't POCOs at all. It's just that they prefer to compromise on encapsulation and performance rather than on parent type. It's probably a legitimate compromise within the limitations of their toolset, but nothing to get cocky about.</p> <p>But the EF works differently; it's every bit as easy to materialize an arbitrary type via LINQ projections as the type you actually mapped. If you're building something to send objects over the wire instead of to be used internally, and must have clients which can't depend on the EF, then you use RIA services or write an ADO.NET Data Service. All the hard work will be done for you. The EF is the basis for a family of tools handling the problem of projecting data in a DB onto various types of clients, not a single, standalone tool which attempts to handle every single data transformation an app might need internally, in one fat framework. Let the EF handle projection from RDBMSs into object space. You can then use, for example, LINQ to Entities to project into persistence-ignorant types, or RIA services to project onto a Silverlight-friendly wire format. Asking one tool to handle every projection any app might ever need is begging to be stuck in a ghetto with that tool.</p> <p>The EF is based around the notion of "value objects." These are types with properties but no behaviors. It turns out that value objects work very well for certain specific problems, like sending data over a wire or sitting in the "no man's land" between the RDBMS and OO programming. <strong>It's important to understand the separation of concerns here</strong>: The point of the entity types is to get the RDB <strong>data</strong> into the object space. You can then write business types which implement your app, and project the entity types onto the business types. You then have the freedom to implement your business types with zero compromises for persistence. And you can change your RDB schema when need be. You need only change your entity mapping and BO projections, rather than the BOs themselves.</p>
    singulars
    1. This table or related slice is empty.
    1. POEntity Framework success stories?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USCraig Stuntz
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POEntity Framework success stories?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COReal world experience was what I was looking for; In the end it may make sense to separate entity classes from behavior classes, although after reading up on Rockford Lhotka's CSLA framework and even writing my own "ORM" inspired by it, I became pretty attached to the idea of self containment when it comes to logic encapsulation. It looks like the EF would be best in service oriented apps where the app logic lives on the service, but I still need data objects to send to the client... EF entities fit this perfectly, and can be sent/received by the logic objects service side.
      singulars
      1. PO
      1. This table or related slice is empty.
    2. CO**The so-called "POCOs" aren't POCOs at all.** If you think about it, non-virtual properties are not plain too, you can put behavior in there, i.e. you can put code in there :-) Where property is the mechanism for an ORM consumer to put intelligence to a model, a virtual property is the mechanism of an ORM makers to put intelligence to their ORM offering. Loading (using session.Load<entityHere>(idHere)) an object from NH is very intelligent, has no performance penalties, it just uses the stub(doesn't hit the database) when you want to use it in many-to-many relationship.
      singulars
      1. PO
      1. USHao
    3. COThe only time the NHibernate's stub object hit the database is when you access its properties other than its id. To some uninitiated EF users, they tend to use what's out-the-box, they will tend to use db.Ent.Find, thinking there's no mechanism to use stub on EF, there is, but it's a world of hurt, you need to detach the stub object if you want to access the real object
      singulars
      1. PO
      1. USHao
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload