Hello,

As a part of quality control in our organization, we are looking for a way to determine the PredicateExpression used to retrieve the collection. I see that, within a partial Collection Class, we can override the DeleteMulti and SaveMulti, but not the GetMulti.

The overall idea is to control at a low level, but within our BLL, what data can be returned in our collections. What would be the best way to do this?

Thank you.

There is not a method you can override to get access to the IPredicateExpression used to fetch a collection. You can maybe inherit some classes to get this working.

What do you plan to do with the predicate when you get access to it (modify it, logging it, validate it)?

Validate, and throw any exceptions in order to guide our developers, is really all we want to do.

As a simple, but valuable, example :

Psuedo Code

If PredicateExpression.Contains(OrganizationIdExpression) = False Then

       Throw New Exception("You must include an OrganizationId predicate when querying this collection.")

End If

So, I understand there isn't any way for us to do this in the Partial Collection class. I don't think we can have our Partial Collection class inherit anything as these collections already inherit the EntityCollectionBase class. Any suggestion of what class, and what event we can override to get a chance to do this kind of validation? Or is this just one of those things that cannot be done?

Thanks.

I see. The thing is that there's no virtual method to override in the GetMulti-call chain so you can't inspect filter to use.

So it's a bit complicated. Nevertheless, a small change to the DQE of SqlServer (or the database you are using) is an option. That means you need to download the source code and find the SqlServerDQE (if the case is SqlServer). As there's just 1 select query construction method (CreateSelectDQ), you can simply check the filter there and throws an exception if you want to.

If you don't want to alter the sourcecode, you can derive a class from the DynamicQueryEngine and override the selectquery construction method. The DAO classes set the DQE to use in the constructor. You could create a derived class for the DAO classes, set the DQE in THAT one's constructor (using a template of course) and then you can let the code instantiate instances of the new DAO classes in the collection classes and entity classes by overriding CreateDAOInstance() in which you create your own DAO variant.

Now, IMHO, this is not something you should check in code. You don't check every code convention in code and throwing exceptions. Otherwise you should check whether they are not deleting unwanted rows, or whether they are not fetching sensitive data, or whether they are setting the correct field values. In my opinion this is something you must check via Tests classes, or by passing an QA process. It's a balance between business rules conventions and Tests.

For Adapter is easier, because you only grant access for DBSpecific project to those programmers working on Fetching and Saving routines in BL. Then the rest of the programmers only use the Manager Classes (aka Business layer) delivered by DAL programmers. This way you have more control on Tests over those BL methods.

After that recommendation, the conclusion is that you can do what you asked for but you have to use above workaround. Hope helpful.