Hi there,

Extending entity classes using partial classes is a little difficult sometimes because the partial class has to be in the same project as the original class definition. Using inheritance doesn't work at all because LLBLGen won't instantiate the sub-class. (or can it?)

I was wondering if its possible to have LLBLGen use Unity to pick the right sub-class to instantiate?

Cheers, Ian.

Hi Ian,

Sorry I'm not understand you a 100%. What is your really need to inherit some entity and LLBLGen automatically use that inherit class? Could you please show us an example of that?

Well I don't have an example at the moment.

I want to add code to an entity class but at the moment the only options seem to be adding code inside the generated code in the custom code sections or creating a partial class of the entity. The problem with both of these is that the code that one adds needs to be in the LLBLGen projects.

What I would like to do is add extra code to an entity class in a sub-class and have the sub-class in a different project where lots of my app's functionality is.

The trouble is that I can't use sub-classes because LLBLGen won't create them - it wil only create the generated sub-class.

The trouble is that I can't use sub-classes because LLBLGen won't create them - it wil only create the generated sub-class.

Unless you derive from that entity's factory class. And override the public override IEntity2 Create() method to return your sub class. Then use this factory whenever needed to let the framework create entities of the sub-class.

OK cool. Would be even cooler though if you could just configure this in web.config as you can with Spring.net and Unity.

Then use this factory whenever needed to let the framework create entities of the sub-class.

That sounds like quite a lot of extra work and that's when you even remember to do it.

Are there any well known gotchas that arise if one has LLBLGen generate its C# files into a business project? I want to do this so that my entities can easily reference code in my business project.

I saw a thread about doing this once before but I can't find it.

How does one go about doing this? Do I have to change all the target directory parameters in the 'Task Queues' area?

What kind of business object class has to be generated exactly? Code which leverages the generated entities?

I mean that the standard generated entities are in the business logic project and not in the normal LLBLGen project.

At the moment my business logic project has a reference to the generic LLBLGen project but if a generated entity needs to use some code defined in the business project it can't because a circular reference results between the projects.

I suppose I could move all my business logic code into the project with the entities in.

I suppose I could move all my business logic code into the project with the entities in.

That's what I was going to recommend.

Hello Gentlemen -

Yes, this is exactly what we've done, as well. We've moved most of our core business logic into the DAL.

Our Business Layer defines all the screens, prefetches, and anything else the screens need (ie, fetches for populating combo boxes, etc.).

Just some reassurance. You're not alone, Ian.

Ryan

Hey Ryan,

So does your Business Layer reference your DAL? If so, if some of your business logic that's in the DAL needs to reference a type in the BL what do you do? Do you extract an interface from the type in the BL and put it into the DAL or do you have a seperate project containing interfaces that both the DAL and the BL reference?

We've moved most of our core business logic into the DAL.

This does sound rather fishy!

About Dependency Injection, you indeed can use LLBLGen DependencyInjection for entity properties (http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=18284). Where exactly do you want to use your subclasses? everywhere? You also could use Unity, etc...

All this depends on what kind of logic are you putting on entities and more important "why".

Ahhh but I don't want to inject the value of a property. I want to inject a sub-class of a generated entity.

I want all the code that I would have otherwise put into a partial class or into a custom code region to be in a sub-class within my domain project.

The poster from your link has added a custom property to a generated entity. I would want to add a custom property to a sub class of a generated entity and have LLBLGen instantiate the subclass!

Don't you think it would be a good feature to be able to add custom code in this way in addition to the existing methods? I think the 'what' and 'why' of the actual code that one would want to add is kind of beside the point.

I am a bit lost what exactly it is that you want. I understand the concept of a subclass ( ) but how that's related to dependency injection in your situation is a bit vague to me. Could you give an example?

So I've currently got a partial class that looks like this...

    public partial class ContactEntity : IEmailAddress
    {
        public string EmailAddress
        {
            get { return Email; }
        }
    }

The point of this is to allow the use of a ContactEntity wherever an IEmailAddress is required. I would prefer to define IEmailAddress and this implementation of it in my app's Domain project but LLBLGen won't create a sub-class. So basically lots of my domain stuff is being dragged into the generated code project which is a bit messy!

What I want to do is define the following in my domain...

    public class MyCustomContactEntity : ContactEntity, IEmailAddress
    {
        public string EmailAddress
        {
            get { return Email; }
        }
    }

This solves my problem of keeping as much of my domain code as possible in the domain project. The trouble is that LLBLGen won't easily create the subclass.

So 'dependency injection' is perhaps a fanciful way of refering to this. I just want LLBLGen to automatically create a sub-class of my choosing.

What do you think??

That has nothing to do with dependency injection .

You can specify the base class of an entity type btw. As long as that class inherits from EntityBase (selfservicing) or EntityBase2 (adapter). You can do that in the project properties, Output setting values: EntityBaseClassNameDefault. You can specify a macro there, i.e. {$Name} to get it replaced at generation time with the entity name, e.g. {$Name}Base, will become for the entity Customer: CustomerBase.

Now, what you can do is this: Your domain project contains classes, one for each entity, e.g. CustomerBase. These classes inherit from EntityBase or EntityBase2. They're all abstract. In these classes you define the domain logic. Make sure the constructors are properly called. Define these as protected. It's key you have the same constructors as CommonEntityBase. In the designer you define the default for the entitybaseclass name, as described above. This will cause the generator to define the base class for each entity to be {$Name}Base, e.g. for Customer the base class will be CustomerBase. You now reference the domain project from the generated code and everything should compile.

However you can also look at seeing domain logic more as a service, as often domain logic affects multiple entities, so spreading that across multiple entities is not that useful.

That has nothing to do with dependency injection

Its a similar principle. One would be configuring the concrete type that an entity factory creates in the same way that one does with an IoC container.

Your domain project contains classes, one for each entity, e.g. CustomerBase. These classes inherit from EntityBase or EntityBase2.

So how does the base class reference properties on the generated entity that its a base class of?

However you can also look at seeing domain logic more as a service, as often domain logic affects multiple entities, so spreading that across multiple entities is not that useful.

Yes its usually just little things like in my example.

Good point, I overlooked that.

If they're little things, why not look into the auditor/authorizer/validator classes? Especially validator classes can help with the BL inside entities which often is about validation. These are all injectable through DI and can be placed outside the generated project.

OK cool I will take a look. Thanks.