Hi I'm very new to LLBLGEN Pro - i'm just evaluating version 2.5 demo right now.

So here's my question - I'm considering LLBLGEN Pro generated code as essentially a replacement for the DAL that I usually have to write by hand.

Now, I need to incorporate my business logic at this point, and I'm wondering whats the best way to get this done with LLBLGEN Pro.

I am considering these factors:

1. Unit testing - I like to have as much business logic as possible to be outside the ASP.NET pages so that each piece of logic can be unit tested. This means even the validation will need to be located in the business layer.
2. Reusability - I would like to be able to isolate the business logic so that it can be reusability by other apps e.g. web services, or web forms apps.

Everytime my database design changes, I need to regenerate the code, so I can't really put logic in there can I?

I started creating a layer between my front end and the generated projects to handle my business logic. But now I need to pass the entities up to the front end layer, so there is little separation between layers anyway, and little value in adding this extra layer if i'm going to do that.

How is everyone else handling this? Any suggestions would be welcome!

Thanks and happy new year!

Dravidian

Normally I tend to use the following architecture (using the Adapter model):

PL ASP.NET app / Windows app ..etc (You can apply inputs validation here)

BL Manager Classes / Business Logic Classes Validation Classes / Audit Classes / Authorization Classes ...etc Business Objects / Model -> Low Level Business Layer generated classes (DBGeneric Classes)

DAL LLBL DBSpecific Classes

Take a look at the following threads, for other opinions: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10387 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10598 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9675

Hi Walaa,

Can you clarify what the difference is between your Manager Classes and your Business Logic Classes. Are your Managers entity specific perhaps?

Cheers,

Peter

you can use partial classes to incorporate project specific business logic within the entities. or use a manager/service/task object to maintain the custom logic.

if your going to be unit testing make sure your make any public properties/function virtual so you can mock them.

I've heard people talk about manager/service/task before but I don't think I understand the purpose of each. I assume that managers contain entity specific behaviour. i.e Customer.GetByPostalCode(), that service contain service specific code i.e PaymentService.Authorize(Customer, Card). Is this right? Also what is the Task for?

Cheers,

Pete

whatever term people use they are implementing the facade pattern. what these objects are used by the interface to hide the complexity of the logic. "complexity" can be a simple as fetching all customers. to more complex operations like fetching the last 5 orders for a given user. obliviously the objects can be even more complex.

they are most used with the presentation layer communicating with the domain (entities).

I assume that managers contain entity specific behaviour. i.e Customer.GetByPostalCode(), that service contain service specific code i.e PaymentService.Authorize(Customer, Card). Is this right?

You got it right.

Thanks everyone for your responses. I've decided to go with Manager-type classes to perform logic and validation between my front end and LLBLGEN layers. Entities will be shared between all layers.

Pretty much like the HnD sample I believe.

Thanks

Dravidian

Good Luck and don't forget to check the LLBLGen docs for the Validation, Auditing, and Authorization features.

Thanks Walaa. From what I've seen Validation is best put in place via partial classes right?

I'd rather not go with that route and keep the validation in a separate layer since a lot of the validation will be cross-entity. Plus I'm still new to LLBLGEN and reluctant to put in my own code in a generated project

Validation can be put in different classes and in different assemblies too. Please check the Validation logic inside validator classes title in the LLBLGen Pro manual under "Using the generated code -> Validation per field or per entity"