50 likes | 388 Views
Austin Code Camp ‘08 Prescriptive Data Access Development in .NET 3.5 Austin, TX May 17, 2008 Brian Orrell brian.orrell@parivedasolutions.com http://borrell.parivedasolutions.com/. * For Internal Use Only *.
E N D
Austin Code Camp ‘08Prescriptive Data Access Development in .NET 3.5Austin, TXMay 17, 2008Brian Orrellbrian.orrell@parivedasolutions.comhttp://borrell.parivedasolutions.com/ * For Internal Use Only *
Many times simple CRUD features seem like no-brainers and their user stories are not given the same amount of forethought and planning as other features of a system • What are the auditing requirements of the system? • Do you need to know every change that has been made to a record? • What information needs to be saved for auditing records? • What type of concurrency should be supported? • If a user changes data after a page has loaded but before it is saved, what should happen? • If data is deleted on one system while being viewed on another, what should happen when an edit is attempted to be saved? • What type of transactional integrity is required by the different entities? • Can an invoice live without children? • Can a customer that has many addresses be entered without at least one? • Where type of data validation is required for the fields of the entity? • Where should the validation live? • What should be the method for displaying validation issues? • How should successful and unsuccessful save operations be communicated? • When an insert is successful, where the user be taken? • When a delete occurs, what should happen? • When an update occurs, should the user remain on the newly updated record?
LINQ to SQL provides a consistent and extensible approach to managing the not-so-simple tasks involved in day-to-day CRUD development • Supports multiple ways to handle optimistic concurrency (Serves as a good base framework to apply even if you’re not using LINQ to SQL) • Will not update the database when no “true” changes have occurred on the UI (Uses a variation on the observer pattern that identifies the real changes that should be made to the system) • Extensible platform for inserting auditing and other logic at the business logic layer(This is the crux of what will go in a LINQ data layer)
Best practices for using LINQ to SQL for Data Access Applications • Use a Timestamp (Version) column whenever possible to ensure proper and performant concurrency checks • Always trap for ChangeConflictExceptions when submitting changes to the database • Form and DetailViews are evil… avoid them like the plague • Do not use Attach using a new entity unless you are maintaining the original values of all the values you are changing • Only use Attach(entity, original) if you are not using a versioning column in your entity • Only use Attach(entity, true) if • You are using a versioning column • You are using a serialized or full-object graph of your entity • Test , Test and Test again • NEVER pass DataContexts around and always surround them with using statements