2

I'm using MVC 3 Razor (c#) and in my view I am displaying an entity where the user may only update the Name property.

public class Product{
    public Guid Id {get; set; }
    public string Name {get; set;}
    public string Type {get; set;}
  }

To prevent having the load the entire object from the database before saving it again, I use a method like:

public void UpdateProduct(Guid id, Hashtable propertiesToUpdate) {}

in a business object, to allow updating of a set of properties of the entity by either a AJAX request or a form Post. (Data constancy is done using timestamps).

I've looked at other methods like using INotifyPropertyChanged to update the property when the change is detected, but this seems only useful if you are able to keep the an instance between requests or loading the entire entity before making a change (which seems heavy).

I see NHibernate uses dynamic-update in a similar idea. Does this cause NHibernate to load the data from the database and do compares before generating the update statement?

Is there a best way of keeping the object being edited (Session[]?) between requests or a less clumsy way of updating individual properties (without moving to a Entity Attribute Value model)?

Yusubov
  • 5,815
  • 9
  • 32
  • 69
Mark
  • 99
  • 7
  • http://stackoverflow.com/questions/1243390/what-is-the-best-approach-to-update-only-changed-properties-in-nhibernate-when-s seems to address a similar idea from a NHibernate side. – Mark Jan 04 '13 at 03:55
  • In the end I used an internal list UpdatedPropertiesList and the update call for the data store checks this list before updating. Works a treat without having to the load the object first. – Mark Oct 13 '14 at 11:21

2 Answers2

0

There is no state in MVC except in the application itself which handles the routing and controller instantiation. You do not want to attempt to shoehorn some sort of state into the application because there is no good way to guarantee that it won't be randomly destroyed like in an AppDomain recycle. Is there something wrong with retrieving the record from the database once when loading the page and again when updating it with the POST data? I believe that is how it is usually done. The only thing that can take a long time with NHibernate is the creation of the SessionFactory, everything else is pretty fast.

Edit: Expanding from your comment, NHibernate is there so that you don't have to worry about the implementation details of the interface between your model (database) and your controllers. It is a framework that takes care of all that plumbing for you. Build your application in a modular way so that important features can be easily exchanged for something else at a later date without it have a ripple effect all through your application. Wrap the NHiberante logic with the repository pattern. Then you can use a different ORM in the future without changing the way your controllers talk to the data layer. You might want to look into Inversion of Control/Dependency Injection to help with this.

mortalapeman
  • 1,415
  • 12
  • 16
  • Essentially that's my problem when trying to wrap my head around ideas like the Onion Architecture. I am assuming the loading the record from the database before updating a field and sending it back to the database is a lot of overhead. Is it worth worrying about about the overhead on such a process? – Mark Jan 04 '13 at 03:08
  • Basically what I am trying to day is don't worry about implementation details, worry about application design. Let frameworks handle the plumbing. – mortalapeman Jan 04 '13 at 03:49
  • Have considered ORM's but avoided them for various reasons. Thanks for the advice tho. – Mark Jan 04 '13 at 03:52
0

In short: the clean way to do that would be getting your Entity identity parameter and set of property values that you would like to update, and passing them to the service layer.

In the service layer, you may call your Repository with Entity identifier and retrieve the single entity and update the specific properties that you would like to do.

However, common approach would be using a DTO objects principle to cleanly streamline your CRUD operations. More about DTO and where it is useful.

Community
  • 1
  • 1
Yusubov
  • 5,815
  • 9
  • 32
  • 69
  • 1
    This is very close to what I'm doing now, thanks for the break-down! Sometimes I find myself getting bogged down in best architecture practices. – Mark Jan 04 '13 at 05:47
  • no problem, taking the simple, straight and maintainable solution is the way to go. – Yusubov Jan 04 '13 at 05:49