Porting MVC Music Store to RavenStoreManagerController
The final part of the port of the MVC Music Store to Raven is the administration section, implemented in StoreManagerController. I am going to show comparisons of all the methods where the port doesn’t offer anything new, and then focus on an interesting conceptual difference between the implementations.
Please note that the main reason that the Raven code is so much shorter is that I threw away the nonsensical error handling (or lack thereof).
Again, throwing away the error handling that isn’t made a lot of the difference in the code.
Now we get to an interesting difference. The old code will delete orders if they include the deleted album. Raven’s code does no such thing.
It is important to understand that there is no such thing as referential integrity in Raven (or document databases in general). This can be a plus or a minus, but in this case, we are turning that into a plus, because we can delete an album without losing orders. I don’t know about you, but I like the idea of keeping the orders around. :-)
A bit more formally, documents in Raven are independent, they aren’t affected by changes to other documents.
There are two more methods to discuss with regards to the StoreManagerController, but I’ll discuss them in my next post.
More posts in "Porting MVC Music Store to Raven" series:
- (31 May 2010) StoreManagerController, part 2
- (29 May 2010) StoreManagerController
- (28 May 2010) Porting the checkout process
- (25 May 2010) StoreController
- (24 May 2010) Advanced Migrations
- (23 May 2010) Migrations
- (22 May 2010) Porting the HomeController, the Right Way
- (21 May 2010) Porting the HomeController, the map/reduce way
- (20 May 2010) Data migration
- (19 May 2010) Setting up the application
- (18 May 2010) The data model
Comments
Deleting orders together with album is not a RDBMS limitation but a design flaw (at least for an order processing software)
Are you handling form validation errors somewhere else now that you no longer catch any exceptions from UpdateModel?
Paul,
No, I am not. try {} catch{} is evil, errors should be handled, not swept under the rug.
But UpdateModel will place the validation errors in ModelState before throwing an exception. Therefore catching the error and redisplaying the view will display those errors to the user. Won't the new code go to the generic error page as written?
Paul,
Probably, but I don't like error handling like that.
Either it should catch ValidationException or it should use TryUpdateModel
Keep up the good work! :-)
Here's a tip for strongly typed Includes:
blogs.msdn.com/.../...ment-include-strategies.aspx
Comment preview