How do you update an entity in EF 4?
For example:
1) Use AutoMapper to generate the CategoryEditModel from a Category entity from the Service Layer.
2) Pass the EditModel to the View. Great!!
3) Post back the EditModel, use AutoMapper to take the CategoryEditModel --> Category.
4) Take that Category and pass it off to the Service Layer which passes it off to the Repository which in turn does an ObjectSet.Attach(TEntity).
Tells me the ObjectStateManager has another object with the same key???
I am using Ninject to inject the Controller with the Service and UnitOfWork, the Service with a Repository, the Repository with a UnitOfWork. The UnitOfWork is scoped per request.
It seems something is being held in cache maybe?
Do I have to call dispose on the UOW or will Ninject take care of it? It does implement IDisposable, and in the dispose it disposes of the context.
Entity Contexts cache objects. It's generally considered wise to keep the life of a particular context quite short. I do this by using a factory within each repository method:
public SomeObject GetSomeObjectById(int id)
{
using (var context = _contextFactory.Get())
{
return context.SomeObjects.SelectSingle(o => o.Id == id);
}
}
If you're quite certain that you want to follow the one-context-per-request model, you'll need to load the entity you want out of the context (which should be free if you use context.GetObjectByKey because it sounds like it's cached in this case), change the values on the object, and then save changes.
I think you should use only a single Entity Framework Session object without having repository. Take a look at this post : Question about Interfaces and DI? and let me know if you have questions. It's code-first and it works perfectly for me.
Hope it helps you!
Related
This is my first attempt, after reading a lot about DDD, TDD and Repository / UnitOfWork paterns, to make my own application.
I'm using Entity Framework, MVC 4 on .NET 4.0 (the server that will be running this application is a Windows 2003)
This is the basic simplified pattern logic (The original one uses a IRepository, IUnitOfWork, GenericRepository and extends the EF POCOs with a IEntity interface to give access to the common ID field. But this simplified example will be enough to ask my question)
View -> ViewModel -> Controller <- UnitOfWork <- Repository <- EntityFramework <- Database
View
Model.Employee.GetSeniority()
EmployeeDetailsViewModel
Employee e { get; set; }
Employee
DateTime dateHired { get; set; }
TimeSpan GetSeniority()
{
return DateTime.Today - dateHired;
}
Controller EmployeeDetails()
using(var unitOfWork = new UnitOfWork) {
return View(EmployeeDetailsViewModel model = new EmployeeDetailsViewModel {
e = unitOfWork.GetEmployeRepository().Find(o=>o.id == id)
});
}
UnitOfWork GetEmployeRepository()
return (_employeeRepository ?? _employeeRepository = new EmployeeRepository(this.dbContext));
Repository Find()
dbContext.Configuration.EnableProxyCreation = false;
Employee e = dbContext.Employees.Where(expression);
dbContext.Configuration.EnableProxyCreation = true;
return e;
Everything actually works properly. The problem is that I feel like something is terribly wrong here, and I'm not sure at which layer it should be fixed.
After getting suggested, by a lot of people (Hi Darin), to always pass ViewModels to views and no models, I started doing this. However, what I'm doing (I think) isn't much better. I'm simply encapsulating my model in a viewmodel. At first, it didn't sound that bad since my Find() method would turn proxy off before getting an object, which would result in a persistance-ignorant POCO. However, now that I want to add some logic in the POCOs, I feel like there is something wrong.
I think the problem resides in where my Business logic is and the fact that my Employee POCO should be mapped to a DTO object. However, where should I transfer the Employee POCO to a EmployeeDTO? Should that be the task of the Repository, the Controller or something else? I'm also unsure of where I should put my business logic (as simple as GetSeniority() displayed in the example). Should that be added to the EF POCO through partial classes or should that be in the DTOs? Or is there another missing step in the Employee -> EmployeeDTO transfer?
This is a great question. It looks like you are trying to find clean separation which is fantastic. I would break the problem up. You have Data Access and you have UI display and in between you have your business logic. If you want to use a Domain model approach here is how I would structure it.
Never expose EntityFramework Entity classes outside of Repository. You can choose to return Dto's (POCO') or Domain objects from your repository. If you want Dto's for more separation, that is fine you will just need another layer such as a service layer to convert the Dto's into Domain Objects.
Put your business logic in your Domain Objects. So Domain.Employee.GetSenority() would be on your domain object.
Any logic that does not fit in your Domain Objects can reside in your UnitOfWork or Service Layer.
Convert Domain objects to ViewModel in controller. At this point map Employee.GetSenority() to MyViewModel.Senority property. Basically your ViewModel is a Dto and only contains view specific logic which typically is not much.
Where do you call the repository. You could use the UnitOfWork pattern as you have it or simply create a Service Layer class. The key here is that these should be useable to other application types. For instance if you were to write a desktop or Windows 8 Style App, you would likely want to reuse either of these along with your Domain Entities.
I'm sure you are having fun with this. Good luck.
I'm developing an MVC application. I have a Domain Model, and I use a repositry pattern for data access and Entity Framework Code First. I also have a UnitOfWork class which I call the repository operations through.
My problem mainly arises when I try to take advantage of aggregate roots and handle child objects through their parent repository.
This is the problem:
Parent class "Supplier" has several Contracts with Departments. I've chosen to make the contract a child of Supplier in this case.
To add a new contract I need to add a method to add a contract in my SupplierRepository, I tried:
public class SupplierRepository : GenericRepository<Supplier>
{
public SupplierRepository(MyContext context)
: base(context)
{
}
public void AddSupplierContract(SupplierContract contract)
{
var supplier = context.Suppliers.Find(contract.SupplierId);
supplier.Contract.Add(contract);
}
And I also tried:
public void AddSupplierContract(SupplierContract contract)
{
context.Entry(contract).State = EntityState.Added;
}
}
When i call
_unitOfWork.save();
I get an error telling me:
An entity object cannot be referenced by multiple instances of IEntityChangeTracker
UnitOfWork instansiates my DbContext (myDbContext) and my SupplierRepository and calls the myDbContext.Save()
Why do I get this behavior
How should I implement an Aggregate Root Repository (CRUD operations for the child objects)
As far as I understand I should have a method in the repository that takes a contract and adds it, and not do this in the Controller of my MVC app, but I don't seem to get it working.
I've seen a lot of information about Aggregate Roots, but no examples of how to implement it.
Thanks.
Solution:
Well I finally figured it out.
So it was not a problem with the repository, but the new SupplierContract queryed the store for the user entity that created it (through an extension method). Obviously this context did not dispose and therefore i had two current DbContexts when I instansiated it to save the contract entity.
Hopefully someone saves time by reading this.
The Aggregate Root repository I solved by just doing like this in the SupplierRepository:
public void AddSupplierContract(SupplierContract contract)
{
db.SupplierContracts.Add(contract);
}
And calling UnitOfWork.Save() method.
While technically you may have solved this issue, I do hope you are aware there's something fundamentally flawed in your design (unless you're using Fowler repositories): repositories (the DDD kind) deal in aggregates only. The fact that SupplierContract needs to be added to the context is not a concern of the calling code. So, why expose that method? I would also reconsider having the repository delegate the save (why else have a UoW). As far as aggregates are concerned I get the feeling you seem to be treating them as structural objects, not as behavioral ones. Hence you seem to be in for a world of pain, going through some of the moves, but not getting any of the value.
To get rid of that error, you should use same MyContext instance to create all the repositories. If you use some dependency-injector, it should allow you to configure same MyContext object through single request. For example, for Ninject, that would be
kernel.Bind<MyContext>().ToSelf().InRequestScope();
MVC 3 + EF 4.1
I'm choosing between two approaches to deal with DbContext:
Instantiate in Application_BeginRequest, put it into
HttpContext.Current.Items and dispose in Application_EndRequest.
Create disposable UnitOfWork (kindof wrapper for DbContext) and
start each controller action with using(var unitOfWork = new
UnitOfWork()) { ... }
Share your experience please: Which one would you prefer? what are pros and cons for each approach?
I would suggest you use a Dependency Injection framework. You can register your DbContext as per request
container.RegisterType<MyDbContext>().InstancePerHttpRequest();
And inject it as a constructor parameter to the controller.
public class MyController : Controller
{
public MyController(MyDbContext myDbContext)
{
_myDbContext = myDbContext;
}
}
If the registered type implements IDisposable then the DI framework will dispose it when the request ends.
1st approach: It is much more cleaner to use ID framework than manually implementing it. Further all your requests may not need your UoW.
2nd approach: The controller should not know how to construct your UoW(DbContext). Purpose is not reduce the coupling between components.
We currently use repositories injected with UoW (unit of work) instantiated via service locator from an repository factory. Unity controls the lifetime this way taking the work away from you.
Your particular implementation will vary depending if your using POCO's, Entity Objects, etc..
Ultimately you want UoW if your going to be working with more than one objectset in your controller to ensure your just using one context. This will keep your transactions in check etc.
If your going to use multiple objectcontexts (ie. multiple EDMX's), you'll want to look at using UoW with MSDTC...but thats probably more than you wanted to know. In the end, the important thing is to ensure you just instantiate what you need for the controller action (i.e. one instance of the context.). I don't think I'd go with Begin_Request, you may not even need the context for every request.
Don't put DbContext in global.asax! :
Static field of DbContext in Global.asax versus instance field of DbContext in controller class?
Entity framework context as static
I'm developing an application using asp.net mvc, NHibernate and DDD. I have a service layer that are used by controllers of my application. Everything are using Unity to inject dependencies (ISessionFactory in repositories, repositories in services and services in controllers) and works fine.
But, it's very common I need a method in service to get only object in my repository, like this (in service class):
public class ProductService {
private readonly IUnitOfWork _uow;
private readonly IProductRepository _productRepository;
public ProductService(IUnitOfWork unitOfWork, IProductRepository productRepository) {
this._uow = unitOfWork;
this._productRepository = productRepository;
}
/* this method should be exists in DDD ??? It's very common */
public Domain.Product Get(long key) {
return _productRepository.Get(key);
}
/* other common method... is correct by DDD ? */
public bool Delete(long key) {
usign (var tx = _uow.BeginTransaction()) {
try
{
_productRepository.Delete(key);
tx.Commit();
return true;
} catch {
tx.RollBack();
return false;
}
}
}
/* ... others methods ... */
}
This code is correct by DDD ? For each Service class I have a Repository, and for each service class need I do a method "Get" for an entity ?
Thanks guys
Cheers
Your ProductService doesn't look like it followed Domain-Driven Design principles. If I understand it correctly, it is a part of Application layer between Presentation and Domain. If so, the methods on ProductService should have business meaning with regard to products.
Let's talk about deleting products. Is it as simple as executing delete on the database (NHibernate, or whatever?) I think it is not. What about orders which reference the to-be-deleted product? And so on and so forth. Btw, Udi Dahan wrote a great article on deleting entities.
Bottom line is, if your application is so simple that services do really replicate your repositories and contain only CRUD operations, you probably shouldn't do DDD, throw away your repositories and let services operate on entities (which would be simple data containers in that case).
On the other hand, if there is a complicated behavior (like the one with handling 'deleted' products), there is a point in going DDD path and I strongly advocate doing so.
PS. Despite which approach (DDD or not) you will eventually take I would encourage you to use some Aspect Oriented Programming to handle transaction and exception related stuff. You would end up with way to many methods such as DeleteProduct with same TX and exception handling code.
That looks correct from my perspective. I really didn't like repeating service and repository method names over and over in my asp.net MVC project, so I went for a generic repository approach/pattern. This means that I really only need one or two Get() methods in my repository to retrieve my objects. This is possible for me because I am using Entity Framework and I just have my repository's get() method return a IQueryable. Then I can just do the following:
Product product = from p in _productRepository.Get() where p.Id == Id select p;
You can probably replicate this in NHibernate with linq -> NHibernate.
Edit: This works for DDD because this still allows me to interchange my DAL/repositories as long as the data library I am using (Nhibernate, EF, etc..) supports IQueryable.
I am not sure how to do a generic repository without IQueryable, but you might be able to use delegates/lambda functions to incorporate it.
Edit2: And just in case I didn't answer your question correctly, if you are asking if you are supposed to call your repository's Get() method from the service then yes, that is the correct DDD design as well. The reason is that the service layer is supposed to handle all your business logic, so it decides exactly how and what data to retrieve (for example, do you want it in alphabetical order, unordered, etc...). It also means that it can perform validation after loading if needed or validation before deleting and/or saving.
This means that the service layer doesn't care exactly how that data is stored and retrieved, it only decides what data is stored and retrieved. It then calls on the repository to handle the request correctly and retrieve/store the data in the way the service layer tells it to. Thus you have correct separation of concerns.
I'm trying to set up NHibernate in an ASP.NET MVC application using a DDD approach. However, I do get an error when trying to lazy load an objects related entity. Heres how I've structured my application:
Infrastructure layer:
Contains mapping files, repository implementations and a NHibernate bootstrapper to configure and build a session factory.
Heres a repository example:
public class CustomerRepository : ICustomerRepository
{
public Customer GetCustomerById(int customerId)
{
using (var session = NHibernateBootstrapper.OpenSession())
return session.Get<Customer>(customerId);
}
}
Domain layer:
Has simple POCO classes, repository and service interfaces
Application layer:
Contains Service implementations.
Heres a service example:
public class CustomerService : ICustomerService
{
private ICustomerRepository _repository;
public CustomerService(ICustomerRepository repository)
{
_repository = repository;
}
public Customer GetCustomerById(int customerId)
{
return _repository.GetCustomerById(customerId);
}
}
Presentation layer:
Contains the ASP.NET MVC application. And this is where I discovered my problem.
Using the MVC approach, I have a controller which, using the CustomerService service, gets a customer and displays the customer in a View (strongly typed). This customer has a related entity Contact, and when I try to access it in my View using Model.Contact, where Model is my Customer object, I get an LazyInitializationException.
I know why I get this. It's because the session used to retrieve the Customer in the CustomerRepository is dead by now. My problem is how I can fix this. I would like if I could avoid getting the related Contact entity for the Customer in my repository, because some views only need the Customer data, not the Contact data. If this is possible at all?
So to the question: is it possible to wait querying the database, until the presentation layer needs the related entity Contact?
I think that what I need is something like what this article describes. I just can't figure out how to implement it in infrastructure layer, or where should it be implemented?
Thanks in advance. Any help will be much appreciated!
As for session management it is common to use single session per request. You can see an example of implementation here. It is an open source project that were designed to setup new asp.net applications with the help of Nhibernate wery easy. source code can be founded here.
Hope it helps.
I also recommend Sharp Architecture.
Another approach, as well as suggestion, is to avoid passing entities to views. There're other problems with it except session management - business rules leaking into views, bloated/spagetti code in there, etc. Use ViewModel approach.
Another problem you'll get is storing your entities in Session. Once you try to get your Customer from Session["customer"] you'll get the same exception. There're several solutions to this, for example storing IDs, or adding repository methods to prevent lazy-loading of objects you're going to store in session - read NHibernate's SetFetchMode - which, of course, you can also use to pass entity to views. But as I said you better stick with ViewModel approach. Google for ViewModel, or refer to ASP.NET MVC In Action book, which uses samples of code from http://code.google.com/p/codecampserver/. Also read this, for example.
Are all your properties and methods in your Customer class marked virtual?
How are you opening and closing your session? I use an ActionFilterAttribute called TransactionPerRequest and decorate all my controllers with it.
Check out this for an implementation.