2

For a new MVC project I was planning to learn and use Entity Framework EF4.1. More as a way of educating myself with EF than for any other reason. A lot of Microsoft developer demonstrations use EF as their data access tool of choice.

However, the more I'm discovering about EF, the more issues I have with it. For example...

I want to save my customers' "basket" at the beginning of the checkout process. It's easy and fast to save the basket to a database using EF4.1. I then want to persist the basket through the various page requests of the buy process. I could use EF to save and re-obtain the basket with each page request. This would work well and mean that I have a saved copy of the basket at every step. However, this might be resource hungry and slow down the process. Therefore I could do what I usually do and persist the basket in session through the buy process. However, I then have have a basket that is "detached" from EF and if changes are made to the basket through the buy process I have to somehow manually synchronise the session basket with the object saved to my database. This could be a fair amount of work and doesn't sound like progress to me.

I've looked at many posts on here and various blogs and the notion of "Self Tracking Entities" looks like it could be the right fit. But many posts on here say STE is a bad idea with web applications.

So, given that many people say EF is not overkill for web applications, what is the best way to deal with the above scenario?

FloatLeft
  • 1,317
  • 3
  • 23
  • 40

3 Answers3

2

However, I then have have a basket that is "detached" from EF and if changes are made to the basket through the buy process I have to somehow manually synchronise the session basket with the object saved to my database

Why? It's a new object, so why do you need to synchronize? You simply need to add it to the database. In other words, nothing is created in the DB until they confirm.

Shopping basket is a natural fit for session. It's silly to keep saving to the db every page, then reading it. Because what if they click cancel? Are you going to delete the "incomplete" object?

Store it in session, read it from session, when they confirm the purchase simply add it to the database:

ctx.Baskets.AddObject(newBasket).

RPM1984
  • 72,246
  • 58
  • 225
  • 350
  • What if he wants to store the state of the basket for later? Cancel would remove this state from DB. – Euphoric Jun 23 '11 at 10:25
  • I wanted to add/update the cart to the database and customer details so that if they do not complete the purchase I have a record of the cart and customer details. – FloatLeft Jun 23 '11 at 10:31
  • Just to clarify here... The basket is a new object at the start of the buy process and because it is saved to the database at the start of the buy process, the basket has to be then synchronised with the database at the end. – FloatLeft Jun 23 '11 at 11:56
  • @FloatLeft - fair enough. That wasn't clear in your initial question. Then yes - you'll have to keep saving/reading to the DB, session isn't an option. – RPM1984 Jun 23 '11 at 23:22
2

However, I then have have a basket that is "detached" from EF and if changes are made to the basket through the buy process I have to somehow manually synchronise the session basket with the object saved to my database.

You have always detached basket because you are creating a new context instance for each request, don't you? If no then you are doing it wrong. Sharing context is anti pattern.

You really have to synchronize state manually. @RPM has a nice post about that.

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Looks like my question here is very similar to RPM's question and he provides what looks like the best answer to my problem ("I've accepted @jfar's answer because he put me on the right track..."). He nearly put me off with his answer... ;-) – FloatLeft Jun 23 '11 at 11:51
0

If you want to persist the basket if, for example, the customer leaves half way through and comes back later (think of Amazon; I have stuff that's been in my basket for months, years even), then you have to store the basket in the database and the user has to be logged in for this to happen.

If that's the case, then you could simply retrieve the basket based on the currently logged in user's id (assuming a user can have only one active basket at once). e.g. Here is Dave, get me Dave's basket from the db please. Oh he hasn't got one, create a new one. That kind of thing.

If you want to be able to add stuff to a basket anonymously and then to turn this into an order if the user logs in, you could store the basket in the session and then, after they log in, retrieve it and store it in the database as mentioned above.

You could also do this anyway, even if the user is logged in, but of course you can't then maintain the basket if they abandon half way through.

Tom Chantler
  • 14,753
  • 4
  • 48
  • 53