samjwest wrote:
I'm generating the Self Tracking POCO entity classes (w/ TypedLists & TypedViews) but that's all. I guess I was expecting to at least get some interfaces or hooks on where to add our cross cutting concerns like authentication, auditing, etc. If I have to write templates to create everything else, then I'm not sure how much value there is over what Entity Framework will create for us. Other than generating 2 way updates, which IS a big thing.
The major advantage with respect to the vanilla EF designer is that our designer has many features the EF designer doesn't have. It's true we don't generate every feature we have in our own framework into the EF codebase (yet). With EF, doing auditing and the like is a tad difficult btw, it's a very closed framework. For NHibernate for example, it's a contrib functionality already provided by 3rd party libraries.
We were sold on LLBLGen partially by seeing things like this on the website:
"Features like auditing, authorization and validation, among others, usually aren't written until it's found necessary to do so, stopping the developer from making the business logic he was working on.
LLBLGen Pro offers these features, and many, many more by default. All a developer has to do, is just use them. "
Is this misleading or am I missing something?
It's a remark of our own framework, which supports all that. It lacks some information regarding other frameworks, I agree with that. We'll look into changing this.
For future releases, we do have planned extra features for the supported frameworks, however it's not always possible to add these features. For example authorization, EF doesn't have extension points to build it in, and auditing is the same thing: it requires an active action from the developer to audit changes, which is not what you want: you want transparent auditing, where changes are tracked in an auditor which provides entities to be persisted with the rest.