Follow on from Part 1
The problem I find with these ‘drag your table on here and it all just works’ tools is……. extensibility. If you want to just have an editing tool then they’re great, but anything custom and it becomes really really hard (To the point where you end up binning it and hand rolling from the start again!). Not so with LINQ to SQL…
Validation
The data layer supports any kind of validation you like, and it just appears to your code like a normal exception. For example, if we want to prevent someone entering a date from the past, we can just go into the pregenerated designer class, find the OnValidate sub and put in our code:
Run our insert code with a date in the past, and this is what happens:
Very very neat solution and doesn’t rely on any complicated overrides.
Extra Custom Code
The other extensibility issue I normally find is when you want to ‘do something else’. Say you want to bill for copied MBytes through the backup service. Where would you put that in? You could do it in the main code, but you can also handle it in the data layer. For example, you can put some code in this ‘attach’ method:
Now whenever we call the Add method, our code runs and we can bill for those pesky copied MBytes.
Note the really cool part… in our parameters for the call to the billing routine, we’re grabbing info from both entities.
Code, Life and Learning 