Guys.
Given a BusinessListBase derived class where should I define the four standard authorisation methods - CanAddObject, CanGetObject, CanDeleteObject and CanUpdateObject? I keep changing my mind as to whether they should be in the list class or in the child objects within the list. I'm currently thinking that CanAddObject, CanGetObject and CanDeleteObject should go in the list but CanUpdateObject seems to fit in better within the child object. Anyone have any thoughts on this?
TIA.
Typically these methods are implemented as static/Shared methods on the child class. Not sure I can make a definitive argument for this approach.
Keep in mind that these methods, along with the Get'X' and New'X' type methods are essentially factory methods. Rocky has explained in the book as well as in some other posts that it was simply a choice to have them part of the BO rather than in a separate factory class. If you are struggling with rationalizing one option versus the other (BO vs. collection), maybe go with a separate factory class and eliminate the debate.
For instance, if we were talking about the Project class in the ProjectTracker app, you could have a ProjectFactory class with the following methods:
bool CanAddProject()
bool CanDeleteProject()
bool CanGetProject()
bool CanUpdateProject()
bool GetProject(guid)
ProjectCollection GetProjectList()
Project NewProject()
Project SaveProject(Project)
void DeleteProject(guid)
void DeleteProject(Project)
Don't hold me to the list; just an example.
One thing I'd suggest is that the answer for BLB is likely different than that for ROLB. In BusinessListBase we expect that the elements in the collection are much more autonomous encapsulated business objects as opposed to ReadOnlyListBase where the elements are often built specifically to be "summary" objects solely for use in that list.
That being the case, it seems like the business objects in a BLB should have the methods themselves. However, to facilitate ease of use, I see no reason why the list couldn't have them as well and just defer to the class it knows it contains.
As was mentioned, there's not really a "right" answer. Just offering some thoughts and options.
Thanks for the input guys. What got me thinking about this is the idea that Business Objects are supposed to represent intelligent data in that they should know who can do what to the data they hold. In Rocky's examples he has the objects throwing exceptions if the UI developer forgets to check permissions before allowing some operation. In the case of BLB objects it is difficult to know where to throw an exception if for example the ui calls collection.Remove(child). Should the exception be thrown in the child or the list and if so where? Clearly there are several choices to be made and I just wondered what the common practice was.
Copyright (c) Marimer LLC