I was just wondering how I should go about implementing breeze's EFContextProvider in a separate data layer project. Also, since that project is a class library and not an MVC 4 application, how should I include this into my project? I don't really need the whole bag of tricks that is in the Breeze NuGet package, just EFContextProvider stuff. I want to implement a Unit of work pattern using the EFContextProvider DbContext wrapper, like John Papa has done in his wonderful pluralsight course. Has anyone done this yet? any tips?
Thanks
We've got a more sophisticated sample coming called "TempHire" that has a full blown UoW with Repos and separate model projects.
Breeze.NET components (the .NET server-side helpers for a Breeze app ... if you're going with .NET) are all in a single .DLL They have no dependence on MVC at all ... zip. There is Web API stuff in there. Maybe that's what concerns you. Well ... remember that this is open source on GitHub. You are not constrained to the Breeze .DLL. Build your own out of the parts you want.
In my view, the UoW is a short hop from Repository. If you understand what a bounded context is and can translate that to a DbContext implementation, I figure you shouldn't need much help making the transition yourself. There's no magic to it.
For everyone I highly recommend Scott Allen's videos on Repository and UOW in the Pluralsight Design Patterns course ... perhaps the clearest, jargon-free exposition of these patterns I've ever seen.
Here is a post from the Breeze folks about how to use a UoW and Repo on the server with Breeze
http://www.breezejs.com/spa-template#server
Related
I am building ASP.NET MVC 5 application.
I read about Repository and Unit of Work (UoW) Patterns here.
These examples use Entity Framework which adds a high-level of abstraction itself.
I am using ADO.NET and not EF. I want to know:
Whether Repository and UoW patterns makes any sense with ADO.NET?
How will my Repositories and UoW look with ADO.NET? Any Samples?
Can I add a separate class library for Repository or to make it a part of DAL?
I've written a blog post which teaches you on how to write driver independent code and how to implement Uow/Repository pattern with plain ADO.NET.
It's a bit too long to include in this answer, but basically the IDbtransaction will represent your Unit oF Work (or be contained in one) and every repository will take the transaction or UoW in it's constructor.
To create a command using a IDbTransaction
using (var cmd = transaction.Connection.CreateCommand())
{
cmd.Transaction = transaction;
//do a CRUD operation here.
}
If you look at the definitions of the patterns, and the patterns required to support them, you'll see that, if you start to implement them yourself, you'll never be wandering far from creating your own ORM. While this is a fascinating task, it's never worth it when you consider NHibernate and EntityFramework.
However, to answer your question, I found Fowler's PoEAA book invaluable in learning how to write my own UoW, DataMappers and Repositories, all based on ADO.Net. It's written by someone who's obviously done it for real, made all the mistakes and then documented them so that you don't have to. I haven't read the article you've linked, however I'm often wary of using articles like this as they only demonstrate a surface-level consideration of patterns like this.
The Unit of Work pattern is more important when you're talking about standard ADO.NET because you have to make absolutely sure that the connections you're opening are only open for the required period of time, achieved by wrapping connections inside using statements.
Unit of Work in ADO.NET would look something like this:
using (SqlConnection con = new SqlConnection(//connection string)
{
using (SqlCommand cmd = new SqlCommand(storedProcname, con))
{
//...
}
}
As you're using using statements to encompass your unit of work, you can be assured that under the hood SqlConnection.Dispose() calls the SqlConnection.Close() method, and SqlCommand.Dispose() calls SqlCommand.Close().
As answered in your previous question, you can separate these two out if you wish to do so, but personally I think they should be the same thing.
Some time ago I wrote a blog post why that very tutorial you've linked is harmful . tldr; a repository uses a DAO implementing UoW, but the repository should not be part of a UoW. Unless you like to complicate your code base/life.
To answer your questions:
Once you're using EF or any other ORM, UoW is automatically implemented there. If you go the micro-ORM path (there is no valid reason to use ado.net directly) , the UoW is basically the db transaction. A repository should always deal with application objects, never with ORM (persistence) objects. If your app objects are used as persistence entities, then you probably have a standard CRUD app, and you don't really need the repository pattern. For simple apps, use the ORM directly (it saves a lot of time).
A Repository makes use of a DAO implementing UoW as an implementation detail. The rest of the app isn't aware of anything outside the repository (interface) itself.
A repository interface is defined where it's used (usually a the Domain/Business layer). The repository implementation is part of the DAL. Note that you should use repositories only for changing the model (create/update/delete). For queries, it's much easier and maintainable to have query services (objects) handling a specific use cases and which work with the db directly.
There's a a LOT of misusing the repository pattern out there, I suggest reading my "Repository for dummies" post to understand that's a very simple pattern which has nothing to do with the complicated examples you're usually seeing.
Where can I find an example of a MVC large solution that has been made with Petapoco?
I'm currently using PetaPoco with MVC. However, I'm using Managed Extensibility Framework (Mef) and the repository pattern. I only state this since your solution shouldn't care if it's PetaPoco, Entity Framework or any other Data Access Layer (DAL). Your end result should be not to tightly couple any framework to your solution - when applicable of course. You'll most likely see the repository pattern in the examples listed by #BalusC - which are great examples by the way.
So, not really on topic with your question, but I think its important to start with the right question - which should be "How should I integrate PetaPoco with a large MVC solution" Think about using PetoPoco with some sort of Dependency Injection like NinJect or using Mef to "import" your repositories.
I hope this helps.
Hi I've been given the task of creating an N-Teir website using the Entity Framework 4 and am coming up against some brick walls, more than likely in my knowledge.
My plan so far was to have these layers
Website (application layer),
What I'm calling Name.Framework (BLL),
Name.Data (DAL),
Name.Entities (contains POCO classes and other struct classes used in website/bll,
Name.Common (utility class)
I've tried to use the repository class, but am struggling to make things work how I thought they would. Below are a few examples of what I'm getting stuck on.
If I want to use .include() would this be in my Repository or is this the responsibilty of the business layer? (and I have no idea how this would work in the BLL)
Same question for .Order()? As I understood it this would need to be in repository or at least passed into the repo in some way?!?
Should I be using the BLL to pass in the Context to the repository/data layer? At the moment when I get an entity from the Data layer any navigation properties that weren't referenced in the repo just come back with 'Object Context Disposed', should the Business layer still hold the context etc so that this wouldn't happen?
Or to summarize this HELP!!!
I need to have this in some sort of order by tomorrow (eek!) as the project leader wants to know if we are going to continue with Entity Framework or move to NHibernate as in-house we have more knowledge of it.
Thanks for any help or suggestions
Matt
Looking for something similar myself I found this. Not looked into it too much at the moment but looks promising.
I'm currently working on a web hobby project with EF4 Code-Only, where I have the following structure ([name] being the name of my project):
[name].Web - An ASP.NET MVC 2 project
[name].Web.Models - Custom view models, along with AutoMapper mappings from my entity objects
[name].Models - My POCO classes, and interfaces for repositories
[name].DataAccess - Some interfaces related to data access, for example IUnitOfWork
[name].DataAccess.EF - All Entity Framework related classes and interfaces
I also have a test project for each of the above, plus a couple of projects with helpers and extensions for the tests.
It might be relevant to mention that part of the purpose of this hobby project is for me to learn how to use EF4 with some design patterns of my own choice (the ones that concern EF in this project are the Repository Pattern and the Unit of Work pattern). Another partial purpose is to build up a code base that I can re-use in later projects, and this has affected the division between projects in my application - for example, if I wasn't concerned with re-use, I'd probably have all data access related classes in one project instead of two.
I've implemented a basic EF, poco, Repository, UnitOfWork architecture largely following this article here:
http://devtalk.dk/CommentView,guid,b5d9cad2-e155-423b-b66f-7ec287c5cb06.aspx
I found it to be very helpful in these endeavors. Don't know if it helps you but others might be interested in the link.
I am trying to learn Asp.net Mvc so I am trying out
this Tutorial.
They talk about the Repository Pattern and how it is easy to change to another data access technology instead of just calling Linq to Sql directly.
Using LINQ to SQL within a controller class makes it difficult to switch data access technologies in the future. For example, you might decide to switch from using Microsoft LINQ to SQL to using the Microsoft Entity Framework as your data access technology. In that case, you would need to rewrite every controller that accesses the database within your application.
Note: I never really understood how an interface worked before reading this tutorial and it's still not 100% clear. I see it now as some sort of 'template' for a class.
After successfully using Linq to Sql I thought it would be nice to try out Ado.net Entity Framework since I've been reading a lot about this. They said using the Repository Pattern would make it easy to switch so I thought I would test that.
My question is: what should I do to change to Ado.net EF?
This is what I think I should do.
Add the Movie.edmx file and configure it(add my movie table).
Write a new class based on the IMovieRepository and maybe call it MovieEFRepository.
Change the parameter in the controller constructor to MovieEFRepository. This is the first thing I find strange because in the tutorial they say that not using the repository will force you to change all the controllers if you change to an other datasource. Don't I need to change every controller anyway since I am specifying the MovieRepository class?
The last adjustment I think I need to do is to change the View. Because it's using the Product class which was created by the Linq to Sql designer. I am not sure how I am going to do this. I guess I should have used some object that wasn't dependent on the dbml file?
Forgive me if I have a slightly simplistic view of Asp.net Mvc. I am webdesigner with a lot of interest for Asp.net webdevelopment.
So after a few days of reading and a lot of googling I got it to work. First I tried to find out what IoC (Inversion of Control) actually meant.
One of the first sites I found was a website with a screencast about Unity. Which is a DI/IoC framework for .Net.
Link: David Hayden screencast on Unity.
Looking at it now this is actually a very good screencast and example on how easy it is to use Unity and IoC/DI. At the time I didn't understand it completely so I went on and kept googling.
One website I kept running into was the one from Martin Fowler.
Link: Martin Fowler - IoC Container and the DI pattern
For me, a person that is a coding novice this website is a little to abstract. Also this might sound weird but the font, line-height and typography on that website was really awful which made it even harder to read.
The next website I read was about Windsor Castle since Alfredo Fernández said it was easy to use.
Link: Castle Project- Windsor Container
The documentation wasn't to bad but I had some problems converting their "getting started" basic example to my Asp.net Mvc application. Also part 2 and 3 were missing from their getting started.
After this I started looking for the different frameworks to see if i could find a really basic example. If I just looked at the first screencast again I would have fixed it a lot sooner but somehow I lost track of it.
Link: Scott Hanselman: List of .NET DI Containers(IOC): very good blog post with most of the .NET IOC solutions.
Link: Phil Haack: TTD and DI using Structure Map: Using the xml configuration file was to complicated for me and i couldn't get it to work.
Link:
Andre Loker: ASPNET-MVC-with-Windsor-programmatic-controller-registration: Didn't try this example. Looking at it now I might have been able to get it to work.
Link: MvcContrib: This adds functionality to Asp.net Mvc. It also has 3 or 4 IOC ControllerFactories build in. I couldn't get it to work I also didn't find a lot of documentation about this.
I had a lot of problems with xml configuration files and I couldn't seem to get them to work. I tried Windsor, Structure Map and Spring.net but I always got stuck with the xml files.
So I decided to go to the Asp.net Mvc site because that's where I started learning about Asp.net Mvc. I found the first screencasts and MIX09 presentations very clear and I understood most of what people were talking about. I got stuck at the second screencast by Rob Conery when building the Storefront application. Because I knew a little more about repository and IOC/DI now I thought it would a be a good idea to start watching Rob Conery's screencasts again. In one of the screencasts he talks about uploading all the samples to codeplex.
Link: Codeplex: Mvc sample apps
I went to codeplex and found out you can browse through the source files without downloading them. I tried to find out how Rob Conery handles IOC/DI with his repositories. So I was glad to see he was using Structure Map but instead of using a xml configuration file he was using a bootstrapper class that registers all the interfaces to their concrete class.
After trying this with my webapplication I finaly was able to get Structure Map to work in my application (Hooray).
He also showed me how to fix the dependency on my Product class that comes from Linq to Sql. He creates an extra object that then gets called by "select new product { }" in the Linq queries.
Wow, this answer is a little longer than I planned but I hope this helps other people like me who are very novice in coding and Asp.net Mvc.
You might have your repository decoupled because of injection, not if you followed just the examples because of
public MoviesController() : this(new **MovieRepository**())
I recomend you to read about IOC, is easy and very interesting, you can use and ioc container like castle windsor.
With that, your contoller will have only one constructor, the one with the interface, and not will need to be changed.
With your entities you can do the same that with the controllers, create an interface for each entity and use the ioc pattern too, with tha you will only have to change your configuration file for your ioc container.
If you don't do these things, your right, you will need to change all you said.
I hope that help! sorry about my english!
I've been reading a few things about ASP.NET MVC, SOLID and so on, and I am trying to figure out a simple "recipe" for small-to-medium ASP.NET MVC apps that would put these concepts together; the issue that I am most concerned with is ending up with controllers that are too complex and being like code-behind files in webforms, with all type of business logic into them.
I am considering the following architecture, for a small data-driven app:
Controllers: only handle requests, call an appropriate service and return the action result to the View;
Models: POCO, handle all the business logic, authorization etc. Depends on repositories, totally ignorant of persistence infrastructure.
Repositories: implement IRepository<T>, use dependency injection and is where my db code will reside; only receives and returns POCO.
I am considering having services between the controllers and the models, but if they will just pass forward method calls I am not sure how useful it would be.
Finally there should have unit tests covering the model code, and unit+integration tests covering the repository code (following the "red-green" practice, if possible)
Thoughts?
Ian Cooper had a good post on exactly this recently:
The Fat Controller
Simple recipe: (view)Presentation Layer using ASP.NET, (controller)Code Behinds or AJAX Services Layer, (model)Application Services layer, Business Model layer, and Persistance/Data Access layer.
Of course you can slice and dice numerous ways to deal with complexities in order to build a clearly readable and understandable application.
For a recent discourse on the subject, which I have found to be very good, check out this newly published book: Microsoft .NET: Architecting Applications for the Enterprise.
These walkthroughs are quite helpful:
MVC Framework and Application Structure
Walkthrough: Creating a Basic MVC Project with Unit Tests in Visual Studio
Also see: aspnet-mvc-structuring-controllers
Rob Conery has the best answer IMO.
Check out his MVC Storefront Application, which comes with complete source code and video tutorials.