StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
15277144
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-03-07T16:57:16.973
FavoriteCount
0
LastActivityDate
2013-03-07T16:57:16.973
LastEditDate
LastEditorUserId
0
OwnerUserId
1781772
ParentId
9665865
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
I've not seen Interfaces used to decouple EF. I know they are used for decoupling with dependency injection, but perhaps there is too much going on with EF behind the scenes for this to work (dynamic proxies, change detection). I'd suggest implementing a Repository layer. Step 1 Start with the simplest pattern - model (Person and Book) in a domain and EF in a DAL layer, using the standard EF procedure for code first. EF implements repository features in the <code>DbSet<Person></code> and <code>DbSet<Book></code> (but of course this type of repository is locked into EF). Make a deliverable app work with this pattern, you can demo functionality quite quickly. This allows you to focus on app logic and not worry too much about persistence. Step 2 Put a repository class or classes between domain and DAL. Replace the domain calls to <code>DbSet<Person></code> and <code>DbSet<Book></code> with calls to <code>IQueryable<Person></code> and <code>IQueryable<Book></code> in the repository. The repository collections initially just point at the EF <code>DbSet<></code> collections. Implement Save() in the repository as well. Initially, it just calls DbContext.SaveChanges(). Check the functionality stays the same. Step 3 Replace the source of the repository <code>IQueryable<></code>'s with whatever is equivalent in your new DAL. This may or may not be tricky, depending on the shape of the new DAL. I followed this kind of process - started with an XML serialized DAL, moved it to EF, refactored one table back to a local XML file, and next step will be to refactor another table to a web service on an ESB. BTW, you mention replacing EF with SQL for performance. We found EF slow for bulk inserts, because of the row-by-row style it uses. To get around this, I implemented SqlBulkCopy within the EF based repository (instead of wholesale replacement of EF which has other features we really liked). It's quick, but takes a while to piece together.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POInterface (interface in interface) in the Entity Framework
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAckroydd
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

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.