Hello, I am new to the exciting world of LLBLGen and was wondering what pattern (SelfServicing or Adapter) everyone is using in their projects? I love the symantics of using SelfServicing, but I want to create such a Facade layer sitting between the UI and DL to add all of the business logic and make the UI developers life a little easier, so they do not have to be to concerned with the various helper objects (ie: Predicates) and being able to provide them with a simplified public interface. The drawback to this approach, is obviously the users can still access the entities 'Save' and 'Delete', etc. methods. Anyone have any ideas or solutions for this? I know I can use the Adapter pattern, but I wanted to brainstorm some ideas before committing myself.

Thanks - MKP

I would use the adapter pattern. thats what i use. it seperates implementation from defintion. It also works better with a distributed architecture.

It does have a bit more developer overhead because you have to code a bit more, but hving the exta control is well worth the extra effort.

I prefer the Adapter model because it gives greater flexibility. It's worth the extra effort. It's not as elegant as using .Save through SelfServing, but you get used to it. After a while you think more about the objects as descrete things seperate from the database when you use Adapter. It makes you think more about how you can extend them and eventually, almost incidentally, save them.

I'd warn you, under adapter, to be sure to get the add-in that generates subclassed entities, and work with those. Makes life easier.

Good luck!

swallace,

can you give a simple example of how you use the derived entities? In your bl do you code against the drived entities or what? I'm curious as I've read the discussions about passing entities across layers and would be interested in a simple example.

I'm a beginner , so forgive me if its a simple question

MarcoP wrote:

Hello, I am new to the exciting world of LLBLGen and was wondering what pattern (SelfServicing or Adapter) everyone is using in their projects? I love the symantics of using SelfServicing, but I want to create such a Facade layer sitting between the UI and DL to add all of the business logic and make the UI developers life a little easier, so they do not have to be to concerned with the various helper objects (ie: Predicates) and being able to provide them with a simplified public interface. The drawback to this approach, is obviously the users can still access the entities 'Save' and 'Delete', etc. methods. Anyone have any ideas or solutions for this? I know I can use the Adapter pattern, but I wanted to brainstorm some ideas before committing myself.

Thanks - MKP

Marco,

I too am new to LLBL Gen Pro. I started out with SelfServicing but recently switched to Adapter.

I wanted a tiered architecture (PL > BL > DL) where the BL controlled the retrieving and saving entities to the data base. With SelfServicing, it is very tempting (and easy) to skip the BL ... Hey, I've got an entity and it has a Save() method, why do I need to go to the BL? Or, I've got the primary key right here (in the PL), why can't I just instantiate and load a new entity with the key? I didn't like those scenarios.

I switched to the Adapter pattern and now my layers have more defined purposes.

In the PL, I initially would create an entity to give to the BL to process, but that was putting a lot of validation and logic in the PL. Now, I just pass the data to the BL and let it create the entity and then save it, etc. If the PL needs data, it can ask the BL for it and it will get an entity or collection in return.

My BL is a handful of classes specific to functional areas of the site. These classes have static methods that perform various activities for the PL. For instance, I have a Security class with a Login() method that returns a Member entity, a Calendar class with an AddEvent() method, etc. The BL is the only place that I want calling the DataAccessAdapter to process entities. It is the only place that you have to deal with predicates, prefetch paths, etc.

Of course, my DL is the generated code from LLBL Gen Pro.

By 'neutering' my SelfServicing entities and going down the Adapter path, I now have more control over the entry points into my database and the ambiguity of "Well, the entity allows it, so I could do it" in the PL is taken out of the equation.

Unlike some other comments that I have seen regarding wrapping the entities in another class or creating new entities for the PL, I have no issues using my generated entities in all three layers. I would prefer it if I could get my entities out of the DL namespace, but other than that, I have no concerns.

Hope that helps. I am actually not very far along in my current endeavor but I am moving slowly and refactoring often as I learn new things. If it were to be a smaller/simpler app with only a short-term lifespan, then I probably would have stuck with SelfServicing.

Regards, Matt