Hi People,

This subject comes up fairly often with LLBLGEN pro. I'm having troubles layering my application, currently it works fine but I'm not 100% happy with it.

Here is what I currently have

Web Application (CS.WEB) (PL) \ Business Layer (CS.BusinessLogicLayer) (BLL) \ Generic Data Access (CS.DataAccessLayer) (DL) \ Specific Data Access Layer (CS.DataAccessLayer.Specfic)

In the business Layer I have a set businessManagerObjects that uses the manager template from CVS with some custom extras, an exception class and validation class for each manager plus a logging framework based on log4net.

This problem is the fact the Entities generated have to be access from the web layer and the business layer (so the go across layers ). Ideally I want them to exist in the business layer and the web have no idea about the LLBLGEN Entities.

The Solutions I have come up with are:

1. Combine the Business Layer with the DAL layer. (Doesn’t really help)
2. Create a set of classes that inherit from each entity LLBLGen entity class generated and use those in the Web Layer and Business Layer (Not sure if its actually possible?)
3. Create some sort of intermediate object (using the DTO pattern) (A lot of work for little gain)
4. Or move the entity classes into the BL by editing the templates.

So anyone tried any of these solutions and how did they work out for you? Any other suggestions?

Sorry if it is confusing.

Thanks! Maxus

If your target is to hide Persistance info from the Presentation layer, then using the Adapter model, you can fairly use the DBGeneric Entity Classes in all your layers.

Otherwise if you want to hide the LLBLGen Pro generated entities from the Upper Layers, then you should use DTO objectcs.

A lot of work for little gain

You may create a template to let LLBLGen Pro generate those DTO objects for you too. Please check the following thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=6261

I understand what you are trying to achieve and why you would want to do that. However, I would recommend going with the Adapter pattern and just coming to terms with dealing with entity objects that originate from the DAL. It is an awful lot of effort to force the entities into some theoretically pure model versus going with a model that might feel a little less clean or ideal but works quite well.

I would think that you would be better served spending your energy trying to solve your specific business problems than trying to re-engineer or add significant overhead to your project for very little real (maybe even only theoretical) gain. We wrestled with the same questions when we first started using LLBL almost two years ago but decided to more forward with the way Frans was suggesting. We currently have a successful site (MyHomePoint) and have no regrets or encountered any obstacles with our chosen direction.

Hope that helps!

Thanks Guys For your Opions,

I am already using the adapter model. All my entities live in the dal layer and I pass them through the business layer. I dont think recreating the LLBLgen entities is worth it. But what I would like is to move them into the business layer so that anything above the business layer only knows about the business layer. But I think your right Mattsmith321 its easy to get bogged down in the application "design" rather than just getting it done

Thanks M

Hi Guys,

Just one last thought, Do you think it would be wrong combining the Business Layer with LLBLGEN layer? so move all the managers and etc into it?

Thanks M

Let's first define the LLBLGen Layer.

Using the Adapter model: There is the DBGeneric DLL, which hold your Business Objects (Entities) definitions, which in fact is the a LowLevelBusinessLayer (LLBL), and I see no problem in adding the other Business classes into it.

Walaa wrote:

Let's first define the LLBLGen Layer.

Using the Adapter model: There is the DBGeneric DLL, which hold your Business Objects (Entities) definitions, which in fact is the a LowLevelBusinessLayer (LLBL), and I see no problem in adding the other Business classes into it.

If you do not want the business rules be available at the UI side then it is better to have a manager class separate from the entity class.

If you do not want the business rules be available at the UI side then it is better to have a manager class separate from the entity class.

I think he meant to have Manager classes in the same DLL (package) as the Business Objects. (i.e. Manager classes side by side with the Entity Classes).

Anyway Manager Classes or business methods are used by the UI. (UI calls the BL)

Yep Walaa is right, So is that an okay thing to do? so the Generic becomes my BL layer and the Specific becomes my DAL layer?

Sorry takes me so long to reply im working on two diffrent projects one uses LLBGen and one doesn't so I only get to work on this stuff every second week.

Thanks M