C# extending a entity framework class

Here my current solution I came up with after some research. But please also post your solutions.

I went with my suggestion in the above edit. However only the affected methods in the DAO require these additional parameters (in my case 2 java.lang.Class Objects). DAO and Service Classes remain generic.

The trick however is to add a Constructor to your Service Class which takes those 2 Class Object Parameters as arguments. Then in the Spring configuration you need to create a service bean per class in the hierarchy you want to use. Example:

<bean id="myService1"  autowire="byName"
      class="MyServiceImpl">
    <constructor-arg index="0">
        <ref bean="CompoundClass"/>
    </constructor-arg>
    <constructor-arg index="1">
        <ref bean="CompoundQueryClass"/>
    </constructor-arg>
</bean>

<bean id="myService2"  autowire="byName"
      class="MyServiceImpl">
    <constructor-arg index="0">
        <ref bean="CompoundClass2"/>
    </constructor-arg>
    <constructor-arg index="1">
        <ref bean="CompoundQueryClass2"/>
    </constructor-arg>
</bean>

where the referenced beans are Class objects created like this:

<bean id="CompoundClass" class="java.lang.Class" factory-method="forName">
    <constructor-arg value="full.qualified.class.name"/>
</bean>

While the affected methods are now a bit cluttered (many arguments) and passing around Class objects seems non-ideal to me (probably I'm wrong) a developer using the framework will not have to deal with the issue. He can create his extended entities and apply the correct configuration. I've created tests for his and the solution those seem to work as expected.

If CompoundClass2 extends CompoundClass (which uses @DiscriminatorColumn) and I call a query method from MyServiceImpl only CompoundClass2 objects are in the result even if a CompoundClass object would match the query too + the right type is returned. No casting needed.

is entity framework designed for Enterprise Applications with a complex domain and DDD approach?

This might be only me, but I have yet to find an ORM that would allow you to create a clean DDD model and have it seamlessly mapped to relational data model. You always need some level of change to your DDD to support the ORM mapping. The lazy loading is one of them. Requirement for public properties or parameter-less constructors is another I noticed.

If not, how we follow the approach of Martin Fowler and Eric Evans in software engineering and enterprise application in C#?

I think that original idea of DDD was that there was persistence layer on top of DDD that was specifically tailored for that specific model. Quite often going as low as pure SQL. ORMs being generic frameworks don't have luxury of that specific way of mapping. Some, like nHibernate, get close simply because of their scale and amount of features. But I still think ORM mappers can't generally be used to map properly designed DDD to relational without changes to the DDD model.