i developed an sample application using Entity Framework 4.0. but now i'm gonne developed a real app for a company. where i would like to implement the DAL with Entity framework with generic repository , unit of work and DI container.
please any one suggest me a real example for the framework..
Thanks
Rusho
Generic repository is nonsense. If you want to use design pattern called Repository you should think about specific repository and aggregate roots.
Generic repository is just a wrapper around ObjectSet / DbSet providing no added value - only additional layer which must be maintained and which makes interaction with EF harder. Also adding repository without clarifying why you want to do that and what it should solve for you is wrong approach - design pattern is a blue print for solving a problem. Not something you should use just because it exists and everybody talks about it.
You can also check these answers where I discuss generic repository and its implications:
Generic Repository With EF 4.1 what is the point
The repository itself is not usually tested?
Related
I have read many pages regarding repository pattern,tons of them are online and each of them starts with we should use it because it makes the application testable and also separation matters,but i also see many opinions against this pattern,or also they say its depends on the application which approach to take,all in all the thing is implementation of the logic must be kept away from controller,can anyone tell me how can i do it if generic repository is not the first option?im new in entity framework
Is it a best practice to implement repository pattern with entity framework 6 (and upper versions)? why? It seems that Microsoft doesn't recommend it!
I think it is a good idea to add repository pattern over entity-framework as it can help you alot in many areas. But it can also add a new layer of complexity. So points to consider are:
Using repository you can limit clients to specific operations. (Can be a pro or con depending on requirements and implementation)
You can also provide ready made functions for complex operations so client don't have to repeats that logic.
Repositories can be made thread safe as DbContext isn't.
Repositories will allow you to be independent of entity framework so in future if you ever need to move away from it you can just changed underlying functionality easily.
You can intercept incoming db operations in repository and do whatever you like with them. e.g. add addition where clause in multi-company scenario.
Testing becomes more easier as it becomes easy to mock underlying functionality.
But Repositories also have others cons.
Look at these Is the Repository pattern useful with Entity Framework?
and Benefit of Unit of Work and Repository Pattern with Entity Framework
I am using Entity Framework 6 database-first. I am converting the project to implement the onion architecture to move towards better separation of concerns. I have read many articles and watched many videos but having some issues deciding on my solution structure.
I have 4 projects: Core, Infrastructure, Web & Tests.
From what I've learned, the .edmx file should be placed under my "Infrastructure" folder. However, I have also read about using the Repository and Unit of Work patterns to assist with EF decoupling and using Dependency Injection.
With this being said:
Will I have to create Repository Interfaces under CORE for ALL entities in my model? If so, how would one maintain this on a huge database? I have looked into automapper but found issues with it presenting IEnumererables vs. IQueryables but there is an extension available it has to hlep with this. I can try this route deeper but want to hear back first.
As an alternative, should I leave my edmx in Infrastructure and move the .tt T4 files for my entities to CORE? Does this present any tight coupling or a good solution?
Would a generic Repository interface work well with the suggestion you provide? Or maybe EF6 already resolves the Repository and UoW patterns issue?
Thank you for looking at my question and please present any alternative responses as well.
I found a similar post here that was not answered:
EF6 and Onion architecture - database first and without Repository pattern
Database first doesn't completely rule out Onion architecture (aka Ports and Adapters or Hexagonal Architecture, so you if you see references to those they're the same thing), but it's certainly more difficult. Onion Architecture and the separation of concerns it allows fit very nicely with a domain-driven design (I think you mentioned on twitter you'd already seen some of my videos on this subject on Pluralsight).
You should definitely avoid putting the EDMX in the Core or Web projects - Infrastructure is the right location for that. At that point, with database-first, you're going to have EF entities in Infrastructure. You want your business objects/domain entities to live in Core, though. At that point you basically have two options if you want to continue down this path:
1) Switch from database first to code first (perhaps using a tool) so that you can have POCO entities in Core.
2) Map back and forth between your Infrastructure entities and your Core objects, perhaps using something like AutoMapper. Before EF supported POCO entities this was the approach I followed when using it, and I would write repositories that only dealt with Core objects but internally would map to EF-specific entities.
As to your questions about Repositories and Units of Work, there's been a lot written about this already, on SO and elsewhere. You can certainly use a generic repository implementation to allow for easy CRUD access to a large set of entities, and it sounds like that may be a quick way for you to move forward in your scenario. However, my general recommendation is to avoid generic repositories as your go-to means of accessing your business objects, and instead use Aggregates (see DDD or my DDD course w/Julie Lerman on Pluralsight) with one concrete repository per Aggregate Root. You can separate out complex business entities from CRUD operations, too, and only follow the Aggregate approach where it is warranted. The benefit you get from this approach is that you're constraining how the objects are accessed, and getting similar benefits to a Facade over your (large) set of database entities.
Don't feel like you can only have one dbcontext per application. It sounds like you are evolving this design over time, not starting with a green field application. To that end, you could keep your .edmx file and perhaps a generic repository for CRUD purposes, but then create a new code first dbcontext for a specific set of operations that warrant POCO entities, separation of concerns, increased testability, etc. Over time, you can shift the bulk of the essential code to use this, while still keeping the existing dbcontext so you don't lose and current functionality.
I am using entity framework 6.1 in my DDD project. Code first works out very well if you want to do Onion Architecture.
In my project we have completely isolated Repository from the Domain Model. Application Service is what uses repository to load aggregates from and persist aggregates to the database. Hence, there is no repository interfaces in the domain (core).
Second option of using T4 to generate POCO in a separate assembly is a good idea. Please remember that your domain model (core) should be persistence-ignorant.
While generic repository are good for enforcing aggregate-level operations, I prefer using specific repository more, simply because not every Aggregate is going to need all of those generic repository operations.
http://codingcraft.wordpress.com/
Reference To This Question
Where one should put the DQL queries? In a service class, or in a controller or maybe in a repository class?
Found a nice article about this, which answers my question. I think it's best to put them in the service class.
How to integrate Doctrine 2 with your Zend Framework application
This highly depends on what your DQLs are doing:
If you have a Query which is doing work on only one entity type I suggest to create your own Repository class for this entity. The repository class already provides you with the methods for find and findAll, so it would fit there good.
Doctrine gives you orm:generate-repositories as CLI tool. Ralph Schindler took this approach as you can see in his example repository.
If you have a Query which affects multiply types of entities, the Service Layer should be the best place to put it.
I have a model library (namespace Test.App.Model.EF) with the Entity Framework implementation in it. This has all of the entities provided in the EF designer for me which I want to use. Within this Model.EF implementation, I have several repository classes. I want to create interfaces for these classes and place them in a seperate interface library (Test.App.Model.Interface). So I do so, obviously the implementation library needs a reference the interfaces. BUT, I notice that the interfaces need to know about the objects in the EF designer (since I want to reuse them). I can't create a reference from the interface library to the ef implementation because then I'll have a circular reference.
So, as I write this, I'm coming to the conclusion that I'll probably need a Test.App.Entities.EF that has the Entity Framework "created" entities. That way my interfaces lib could reference without having to know about the Model.EF.
Does that sound like the way to go?
Ok, so after much wrestling with this, I found the buzz term that describes the situation. What I'm looking for here is called "Persistence Ignorance". This is what would make what I described in my thread happen. Well the Entity Framework that we use (not 4.0) does not support this yet (unless you go homegrown like done here).
With having that said, EF 4.0 will have this feature but from what I understand, it's coupled with .NET 4.0 (why it's called EF 4.0 in the first place) and that's not going on our production servers anytime soon. Since we've decided to go with this technology, our repository abstraction to interfaces will be placed on hold until upgrading to 4.0 is a viable option.
Let this be a caveat for those seeking the same information. Please also let me know if this sounds incorrect (because I would love to make this happen sooner then later but I don't want my team jumping through hoops when a later implementation will remedy the issue). Thanks all!