Ok, so I'm still working on keeping my layers separate from each other. I am using the adapter model. In my BLL, I have a StudentManager class with a static method to return to me an instance of my own MyStudentEntity which I have inherited from the generated Entity class in my DAL. This custom entity has a few of my own properties that I want to add.

So, in MyStudentEntity class, I have the following references:

using HLPUSD.SMART.DAL;
using HLPUSD.SMART.DAL.EntityClasses;
using HLPUSD.SMART.DAL.FactoryClasses;
using SD.LLBLGen.Pro.ORMSupportClasses;

...which is just fine because my BLL should be able to see my DAL.

Now, in my PL, I want to create an instance of MyStudentEntity, so I do this:

MyStudentEntity se = StudentManager.GetStudentFromStuID("123456");

...which calls this static method in StudentManager:

public MyStudentEntity GetStudentFromStuID(string stuID)
{
     DataAccessAdapter ad = new DataAccessAdapter
     MyStudentEntity s = new MyStudentEntity(stuID);
     ad.FetchEntity(s);
     return s;
}

I suppose I should mention that in my PL, I have a reference to my BLL but NOT by DAL. The problem happens when I try to compile because I get a "Referenced Class 'HLPUSD.SMART.BLL.MyStudentEntity' has base class or Interface 'HLPUSD.SMART.DAL.EntityClasses.StudentEntity' defined in an assembly that is not referenced. You must add a reference to 'HLPUSD.SMART.DAL'"

When I add that reference and a reference to SD.LBLGen.Pro.ORMSupportClasses then my solution compiles. So, does that reference requirement mean that my PL somehow needs access to my DAL? What are the possible ramifications of adding this reference into my PL project? I presume it may not separate my tiers, but that is less important to me than actual functionality. I guess one area of possible concern is future use of remoting. Does this pose any foreseable problems if I reference my DAL inside of my PL project but do not use any code in my DAL specifically?

Oh, and sense I'm still learning, please suggest any improvements you may see. Thanks.

-Nick

I beleive that what you are encountering is basically a weak / indirect reference.

Aside from holding and defining data, your entity classes and custom entity classes shouldnt be doing much more work. Just like the orm support library really doesnt do much work on the database itself. So its ok for the client to know about these assemblies.

However, with respect to a distributed application you might want to keep the classes that work on the database in a seperate process or on a seperate machine, or both. So, since your managers are doing the work and the client needs to access them, the only real way to seperate the managers from the client is to create a services layer that contains interface definitions / public contracts with which the client may interact with.

The managers methods would need to be wrapped by the interface methods and the client would create objects via the interface methods. Both the client and server would need a reference to the interface assembly as well as the assemblies containing the entity and custom entity definitions, but the client would not need a direct reference to the managers assembly because it will access the managers via the interface.

Hope this helps.

Devildog74 wrote:

I beleive that what you are encountering is basically a weak / indirect reference.

Aside from holding and defining data, your entity classes and custom entity classes shouldnt be doing much more work. Just like the orm support library really doesnt do much work on the database itself. So its ok for the client to know about these assemblies.

However, with respect to a distributed application you might want to keep the classes that work on the database in a seperate process or on a seperate machine, or both. So, since your managers are doing the work and the client needs to access them, the only real way to seperate the managers from the client is to create a services layer that contains interface definitions / public contracts with which the client may interact with.

The managers methods would need to be wrapped by the interface methods and the client would create objects via the interface methods. Both the client and server would need a reference to the interface assembly as well as the assemblies containing the entity and custom entity definitions, but the client would not need a direct reference to the managers assembly because it will access the managers via the interface.

Hope this helps.

Thanks for the input. I understand what you are saying an see where I went astray. I guess my big problem is that LLBLGen provides such a rich feature set "out of the box" that I'm struggling with hiding that functionality. I understand the theory behind why it is good to do this, but like Frans (and others) has said more than a few times, rather than adhere to some ideaology just "because", adhere to what works in your specific circumstance.

I find myself though frequently trying to replicate functionality provided in LLBLGen in my manager classes, so then I have to ask myself, why am I doing this? Either I haven't made that next mental leap into "Abstraction Nirvana" or it doesn't really exist.

-Doubting Thomas