Hi,

I'm currently trialing LLBLGen Pro to see if there is a way to handle record filtering (based on a user's access rights) in a central place. Our Firebird database currently uses updatable views to achieve this, and this was problematic in Microsoft Entity Framework as views seemed to be read-only, relationships get lost, etc.

With LLBLGen I seem to have similar problems: - Entities mapped to views have all fields "not null" and this cannot be overridden as EF complains about the mismatch. - PK's / FK's must be manually maintained. - Mapping to the underlying table (to retrieve the schema information) and then simply repointing to the view seems to produce an invalid EDMX.

Desperate for a solution, I've discovered the Authorizers and whilst I'm not keen on the extra overhead of filtering records client-side, if they can act as a "catch all" for all scenarios including lazy loading I will consider it.

My questions: 1. Have I missed something in how to map entities to views? 2. Are there other tricks I could employ? 3. Will injecting CanLoadEntity 100% prevent materialization of entities that should not be accessible? 4. The sample Authorizer code in the LLBLGen documentation makes use of EntityType, which I can't see defined in my generated code. I just found System.Data.Metadata.Edm.EntityType which appears to be something different?

Thanks!

Which framework are you using? (LLBLGen's or EF's) The Authorizer component is in the LLBLGen Pro Framework.

Hi,

I just output a Model and Persistence project from LLBLGen, then added a reference to 'SD.LLBLGen.Pro.ORMSupportClasses.NET20' to the Persistence project, in order to get the AuthorizerBase. Have I missed something?

Cheers, Ken

KenC wrote:

I just output a Model and Persistence project from LLBLGen, then added a reference to 'SD.LLBLGen.Pro.ORMSupportClasses.NET20' to the Persistence project, in order to get the AuthorizerBase. Have I missed something?

Hi Ken. With your first post, it seems that you are using EF. LLBLGen Pro support a lot of frameworks including EF and LLBLGenRuntimeFramework. It's not obvious to us whether you created your project to target EF or LLBLGenRuntimeFramework.

This is important because Authorizers and thus SD.LLBLGen.Pro.ORMSupportClasses.NET20 are useful only if your LLBLGen project targets LLBLGenRuntimeFramework. If you target EF, LLBLGenPro (Designer) will just generate the EF code for you. The things you can or you cannot do in EF (i.e. built-in Authorizers) is up to EF. If you want to target EF, then you must find on EF docs or additional components that allow you to do this.

The authorizers etc. have to have deep integration within the o/r mapper core to be reliable. EF doesn't offer that kind of interception, so we can't develop that kind of integration for EF. The authorizers/auditors are a feature only of our own framework at this point because of this.