Business Layer - Suggestion request
sparmar2000 wrote:
It seems to me that the layer that LLBL Pro generates could be clasified as Data Access layer (please excuse and correct me if I am wrong).
With the risk of starting a naming-game, I think the layer generated with the current template set can be seen as a BL Facade tier: it's not a raw DAL, because it hides away data-access code, it lets you work with entities, not with data read from a database. 
If this assumtion is correct, then there is a need for a 'Business Entity (BE)' and a 'Business Process (BP)' layer. Business The Business Entity layer would encapsulated for example a OrderHeaderEntiry and OrderDetailsEntity (generated by LLBL). The Business Process layer would encapsulate BE's and provide funtionality such as 'PlaceOrder'. This functionlity would carry out the required business rules e.g. security - is the client logedon, check inventory etc.
Beware by using inheritance for this. Some people argue to simply inherit BE's and add BL code to these classes, however BL code most of the time spans more than 1 entity plus is often part of a process (i.e. multiple steps towards a goal). Better, IMHO, is using Managers, like 'OrderManager', which manages ... Orders and consumes entity objects generated by LLBLGen Pro, which can be order entities, customer entities etc.... It exposes a set of functionality to manage orders, which can be the target of the GUI.
The question to you is: 1. Can I inherit all the properties of LLBL generated entity i.e. OrderHeaderEntity in my BE class, and if required overide them. If yes, then an example would be useful.
The current template set has a limitation that when you inherit from a generated entity class, you can't create collections with these classes automatically. You can overcome this somewhat by using the derived entity classes generated in the two-class scenario. You can override properties in the derived entity classes (for example: entity Foo has two classes (hence the two-class scenario 
): FooEntity (which is the derived class) and FooEntityBase (which contains the raw plumbing code)). You can thus override Foo's properties in FooEntity, since these are defined virtual. By using the Two class scenario Full/Safe (set this in your preferences as your prefered scenario before starting!), you can generate this code and preserve your own code.
- Is there a better way to implement rater then this 3 layer architecture.
I'd go for a middle tier, with your BL code, inside 'Manager' classes. The big advantage is that these manager classes can offer a logical API to the GUI, and can consume the BL facade tier LLBLGen Pro generates, and because you concentrate logic which belongs together, for example logic which forms a business process, the application is more maintainable because you know where what is done (which business process is implemented where), in a separated manner (which is the whole purpose of n-tier development).