I'm having an internal debate about where I should handle checking for changes to data and can't decide on the practice that makes the most sense:
- Handling IsChanged in the GUI – This requires persistence of data between page load and posting of data which is potentially a lot of bandwidth/page delivery overhead. This isn't so bad in a win forms application, but in a website, this could start having a major financial impact for bandwidth costs.
- Handling it in the DAL – This requires multiple calls to the database to check if any data has changed prior to saving it. This potentially means an extra needless call to the database potentially causing scalability issues by needless database queries.
- Handling it in a Save() stored proc – This would require the stored proc to potentially make an extra needless call to the table to check, but would save the extra call from the DAL to the database. This could potentially scale better than having the DAL handle it, but my gut says this can be done better.
- Handling it in a trigger – This would require using a trigger (which I'm emotionally averse to, I tend to avoid triggers except where absolutely necessary).
- Don't handle IsChanged functionality at all – It not only becomes hard to handle the "LastUpdated" date, but saving data unnecessarily to the database seems like a bad practice for scalability in itself.
So each approach has its drawbacks and I'm at a loss as to which is the best of this bad bunch. Does anyone have any more scalable ideas for handling data persistence for the specific purpose of seeing if anything has changed?
Architecture: SQL Server 2005, ASP.NET MVC, IIS7, High scalability requirements for non-specific global audience.
Best Answer
I handle it in the DAL - it has the original values in it so no need to go to the database.