Using LinqToSql in a real-world application RRS feed

  • Question

  • I'm developing a 3-tier WPF/MVVM application using LinqToSql in the data access layer and I have some questions about how it's used in real-world applications. I see lots of sample code across the net and plenty of simple demos but what about a real-world relational DB with tens of thousands of records across dozens of tables? Specifically:

    • How do you convert LinqToSql records to data layer objects? Reflection? Manually?
    • If you load object A and it has a relationship to object B then what determines when object B gets loaded? Automatically in the data layer via its get accessor? Or higher up e.g. in the ViewModel?
    • How do you keep track of when objects in the data layer are no longer needed? Reference counting? If so then when a data object is released/freed how does it know which of it's member objects need to be released? Manually? Reflection?
    • What should the lifespan of a DB context be? Do you keep it open for as long as the user is editing records it has returned? Or do you close it immediately and then if the user user changes a record create a new one, attach and save?
    • What if you want the user to be able to edit the same object in multiple windows simultaneously but you don't want those changes committed until they hit save? Do you cache the Linq object and give each window it's own data layer object? Or do you have multiple Linq objects as well?

    Are these issues that all database programmers have to deal with on a per-project basis, or are there "standard" or "proper" ways that most people handle this stuff? I've never developed a major DB application before, I feel like I have all these little pieces of information but I'm not quite seeing how they all fit together.

    Any suggestions on reading materials that specifically address these practical problems would also be appreciated.

    Tuesday, June 5, 2012 1:36 AM