Well, I'm not sure that the framework
could handle this situation correctly. As has been mentioned, there are a bunch of ways to handle this (ensuring that children records are deleted before deleting a parent record), including setting up the tables so you never have to do this sort of check. There is no way for the framework to know what particular approach you'd take, so any arbitrary solution would be limiting. So, instead the framework does allow for special cases. In this case there are at least three choices:
- sub class BusinessLayer, override OnBeforeDelete, which offers the best control
- handle the BeforeDelete event of the form
- Handle the BeforeDelete event of the BO
- ...more I'm sure
The trick is to understand how things work enough to get the right solution for your needs. Unfortunately, that just takes time and what you are doing right now...asking lots of questions (I should know, I've asked about a million
). When I was starting out, I often felt the same...the SF framework should do _____ (fill in the blank). Often it was more I just didn't understand how easy all this subclassing makes things (plus all the other .NET goodness). I'm refactoring some code I wrote about 6 months ago...boy did I do things the hard way then. I'm sure in another six months, it will be the same again (although by then, I'll likely be in VS2008, with linq, so god help me!
). Of course, many of your suggestions are excellent and given some more time, I'm sure we'll see the BO Mapper doing lots more work for us, etc.
So, don't get discouraged, it'll get better sooner than you think..you're working hard and asking the questions!
Good luck!
Greg