I'm going through a few tutorials to learn Razor and EF and it is stated that this is how to update a ProductPass the product in and save the changes on the context.

public void SaveProduct(Product product)
{
context.SaveChanges();
}

but it doesn't seem to work. No changes to the database but it will pass a message back to the view that it was updated and give the name of the product if I try that, it just doesn't get to the database.I have to do it like this instead:

I can't explain why it doesn't work as the tutorial says and I seem to remember having the same exact issue with the MVC1 version of the tutorial. Am I doing something wrong or does it just not work like the tutorial says?

This is a prime reason you don't pass entities to views. At the end of the request that sent that Product to a view, your context was disposed, leaving the Product detached. The instance incoming to your save action isn't attached either. Your call to save changes works, it just isn't updating your product because it doesn't know about it.

Your best bet is to convert the entity into a view model first, send it to the view, and then on post action, refetch it and update it.

Ah, well, it could just be a publication oversight. Also, I noticed the method you posted didn't seem to be an mvc action, as it returned void. It may be part of a bigger solution, such as a repository implementation. In which case, they are still doing it wrong. Repositories should not expose work related methods. That's the job of the unit-of-work. But that's another issue altogether. Just remember that sometimes final editors of printed material may not be in tune with the material being printed and don't always catch things the author might. Keep working through the book, and if you have problems, then come here. One of us will surely advise. =)

Well, since you seem to be learning about repositories, I'll save you some time and headache.

The most important thing about repositories and units of work is that they are two very distint types of constructs, with very different goals in mind. A lot of the online tutorials I've seen suggest that you should either pass a unit of work into your repositories, or let the units of work act as repository factories. Both of these methods are fundamentally wrong in their implementation. A car and a train have two different roles to fulfill. You wouldn't expect a car to produce the functionality of a train, or have a train produce a car upon request would you?

Let's look at the industry standard unit of work interface as defined in the PoEAA book:

The role of this object should be obvious. As it's name implies, it perform the work, or heavy lifting, for the application. It's only job is to batch-transactionalize insert, update and delete commands. This leaves relatively few things for the repository to be responsible for. So let's take a look at what's left:

The repository and unit of work act as separate contracts. Neither should be injected into the other, nor should either act as a factory for the other. In this arrangement, the name 'repository' is a bit of a misnomer. The name suggests 'the place you put things', but in reality it is 'the place you get things'. I'd call for a change in name, but it's too widely used under this name.

So how would you go about implementing these? First, let's do the repository, as it is the simplest:

1) Why did you declare TEntity as class when it should be a common entity base class?

You can, and should. At first, you may simply use a common "Entity" base class, but as you progress, you will start using distinct types for aggregate root and dependent entities, at which point, you will want to force your repository to act only upon aggregate roots. For now, an exact type isn't required.

2) Why did you declare the id parameter of GetById as object?

This is a good idea because, as you progress, you will find yourself using things other than a db-filled int. The Find method supports any type usable as an id, including int, string, Guid, and others. Having this method be open to any id type means less work on your part.

Ok, now let's take a look at the unit of work implementation. This one is a little more involved, so take your time and review the sample code:

The repository is injected into the controller, as it will be used in almost every single action. The unit of work will only be used when work is needed, and is therefore instantiated through the factory class.

I hope that heads you in the right direction, without having to read through an entire volume.

Not really. I don't use EF personally. I go back and forth between an NHibernate solution and CQRS with Event Sourcing for bigger things (which means raw SqlClient in Event persistors). My NHibernate uow looks like the following, since we have access to an actual transaction object with _session.BeginTransaction(IsolationLevel.ReadCommitted), so I just put something in there to fill the gap:

Just use Raven and forget about repositories, units of work and mappings for good. You actually get to spend your time building the application instead of the data access layers. Not used it (Raven) for a month or so (currently developing with node and Redis primarily - great fun to work with) but other than a few looks in the management studio you won't have to bother with data access rubbish again.

Just use Raven and forget about repositories, units of work and mappings for good. You actually get to spend your time building the application instead of the data access layers. Not used it (Raven) for a month or so (currently developing with node and Redis primarily - great fun to work with) but other than a few looks in the management studio you won't have to bother with data access rubbish again.

I've looked at it. Though most of my high $ clients insist on MS only products. That narrows my margin of choices a bit. When using CQRS, I don't use an orm at all either.

Since you seem to have spent more time with it though, here's a question for you. How does it handle private fields with no public getters?

I've never been in a situation where I've needed private fields, but you should be able to assign them with the [JsonProperty] attribute and they'll get stored. You could use private setters on properties so that they can't be changed externally. Raven is a good solution for CQRS based solutions if you're event sourcing, there are a few examples lying about using it (although if you've spent the time to learn CQRS you've probably come across them).