Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Looks like the repository pattern is solution for everything ... Repository is not a silver bullet!</p> <p>I'm using the repository pattern with EF everyday because when I started my current project several months ago it looked like recommended solution. My conclusions:</p> <ul> <li>Repository makes interaction with EF much harder. Just browse questions related to EF tags and you will see what complexities must be handled directly on the context, changetracker, etc.</li> <li>Generic repository is something that works for CRUD operations but not for real DDD scenarios. Once your repository works with aggregate roots (DDD) generic approach fails.</li> <li>Unit testing doesn't work at all because general idea that you will mock repository and test your upper layer without dependencies to EF and database fails once you expose <code>IQueryable</code>. Linq-to-entities is only subset of Linq-to-objects and mock doesn't handle referential integrity so many times I saw green unit tests and runtime exceptions. The correct testing approach with EF are integration tests. Mocking repository is only for testing real business logic not related to data access. If you don't have integration test for your business method accessing or persisting data you didn't test it.</li> <li>Exposing specialized methods like GetByXXX is just step back. Most of these methods are used only once. You will end with the code similar to repositories used for wrapping stored procedures calls. Many developers like ORM just because they can avoid such rigid architecture.</li> </ul> <p>EF itself already offers repository pattern - <code>DbSet</code> and <code>ObjectSet</code> are repositories and <code>DbContext</code> and <code>ObjectContext</code> are Unit of works. So in my opinion repository pattern is overused. It can be useful in large projects where you need strict layering or in case of placing additional logic to its methods. Using repository just because you want to wrap access to EF is often valueless code and just additional layer of complexity. </p> <p>You can in the same way create reusable methods defining your queries.</p>
    singulars
    1. This table or related slice is empty.
    1. POOrganizationally, where should I put common queries when using Entity Framework Code First?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USLeniel Maccaferri
    1. USLadislav Mrnka
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOrganizationally, where should I put common queries when using Entity Framework Code First?
      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. CO+1 I used to be in the Repository camp all the way, but I concur with everything stated in this post - it just makes a lot of things much harder and less clean than they are supposed to be. Since it's baked into my current design I will have a hard time giving it up now, but starting from scratch I'd think twice about it.
      singulars
      1. PO
      1. USBrokenGlass
    2. COI see your points here, however you did not offer alternative solution? Services passing Specifications as constraints (Lambdas)? How do you/would you setup data access?
      singulars
      1. PO
      1. USPaul
    3. COThat was my sense too... but can you elaborate on how you'd organize the suggestion you made "You can in the same way create reusable methods defining your queries." -- exactly, where?
      singulars
      1. PO
      1. USScott Stafford
 

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