I am currently moving an existing web project to MVC and adding new features in the process. One of the features will be the ability for have photos and associate them to different items on the site.
I am planning on having one table for the photo, and many linking tables so I can relate the photo to different items (instead of having a column for each item in the photo table):
In the previous website, I would have created a class for each of the linking tables and call the CRUD methods of each class depending on what I was doing. However, recently, I've seen two different examples that use "navigation properties" to handle this sort of scenario.
Using navigation properties, the Photo class would have a list of Singers associated with this photo. So when I wanted to delete a specific row in the Photo_X_Singer table (which removes this singer from the photo and removes the photo from this singer's profile) I would need to load the photo class, then load the Singers property (could be done using lazy loading) and then call DeleteSelf() on the specific Singer.
I can see how this approach would make sense on a smart client that would keep the objects in memory, however, since I'm doing this on the web, I think it make more sense to call Delete(photoId, singerId) on the Photo_X_Singer class??
I agree with your approach.
Why bother to fetch and load a BO just to delete a row in the DB that you already have the key values for?
However, it would be nice to do things like:
Which abstracts out the fact that there is a linking table between the Photo and the Singer.
Copyright (c) Marimer LLC