Hi,

In my tiered web application, my business layer is consuming LLBLGen entities (adaptor model), and passing "custom entities" back to the UI layer. The reason I decided to do this rather than to pass back the LLBLGen entity itself was that it meant that:

a) I can easily add extra properties to my entities; and b) My custom entities can inherit from a "base" class; and c) The UI doesn't need to know about LLBLGen, it juest recieves custom entities, which are stripped of anything apart from the properties.

My question is: Does this sound like a good idea? Now that the new beta of LLBLGen allows custom properties to be added to the entities, I may be better of sticking with the LLBLGen entities instead.

Any comments welcome.

Hi MattWoberts

We investigated this about a month ago and found that ther are basically 2 methods of doing this. We use the selfservicing model.

Method1

Your design sounds simular to the approuch that we decided on - Having BLObjects wrappers around entities.

except for:

passing "custom entities" back to the UI layer

I don't know if this is a good thing. Rather let the UI construct the BL Object and let the BLObject expose the entity properties. This BLObject should be able to expose properties of more than one entiy. Almost like a flat record structure - the bl handles the construction of the relationships.

Graphical Presentation of our structure:

BaseBLObject | | |-DerivedCustomBLObject <--- Implements one or more LLBLGen Entity or Collection | | |-Expose Properties

We decided to use this approuch as this gives the presentation layer the ability of not needing to know what the underlying database structure is or about LLBLGen. This also allows us to handle the saving and getting of information from the BLObject instead of letting the Presentation Layer call the save or get methods on the actual LBLGen entities. It also gives you good place to put your transaction handling and validation.

Method2

Another method that we considered was to maybe inherit from the Entities and overwrite the Save, validate and get methods.

Problem 1 with this method is - Your derived entity will link to the normal LLBLGen entities that end up bypassing your derived entities logic. See 1st reply to NetLearner at http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=831&StartAtMessage=0&#4028

Problem 2 with this method is - Your Presentation Layer is going to need to know how the underlying structures works - it gona need to know about LLBLGen because you are exposing the DL through the BL as properties with this method.

Problem 3 with this method is there is a good chance of your Bussiness logic ending up in the Presentation Layer instead of the BL (So this means you are back to square 1 again )

I don't know if there is a documented good way of implemention BL Layers with LLBLGen - There are several documents on the Net that covers several approuches each with it's advantages and disadvantages.

I hope this helped.

Wayne

Thanks wayne!

I too wanted to prevent the UI from having to know about LLBL, its good to know other people are thinking considering these things

I considered your model very carefully, and I can see the advantages to this way of working. The reason that I am using custom entities is:

1. We are used to this from a DNA world, and it seemed to work well then.
2. I like the seperation of "code" (i.e. service code) and entities. The "adaptor model" in LLBL already seperates the entities from the "data retrieval", I take it one step further and create really lightweight entities that can be passed to the UI. The UI can then modify any of these as is needs to, and when its time to "save", it can just do this:

BLLClassObject.Save(entMyEntity);

I guess it goes back to the "what works best for the app/situation" question. As an example, our application needs to run lots of stored procs and return data that comes from a number of tables. Using my design, this can simply be accomplished by a method in our BLL, e.g. "ListXXXByYYY". We can simply pass them back to the UI as a datatable. In your design, I think we would have to do the same as we can't map this datatable to a property of the BLObject so we would struggle slightly...

Are you aware of any web references for business layers using LLBLGen on the net? I have read some general ones (mostly Microsoft patterns/practices), but have never come accross any articles about using LLBLGen in business layers...?

Matt.

It is always a good rule to always encapsulate the data from the DL in the BL in such away that the PL never requires anything of the DL otherwise the use of BL is useless and you might aswell be coding the BL in the PL. I havn't seen any docs about BL's with LLBLGen except for this forum.

Business Layers are very complicated if you look at the requirements people put on them. A BL Should... 1. act as a "Interpreter" between PL And DL. 2. be able to handle replacement of DL with ease. (As Otis says in http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=723 "It's a myth") 3. be able to be reused by other applications. (Yah right - this almost never happens) 4. Should be scalable.

I like flow charts - if you look at a flow chart of how the data is suppose to travel from your application and DB to each other you will see that the BL is a "Interpreter" denormalizing the data from the DL for the PL.

**PL >- BL-< DL - DB **

As i hope you can see above the BL is responsible for taking data from multiple places and giving it to the PL in a almost single record structure \ method structure.

The catch is that the BL has to be able to return multiple rows with filters applies and return single rows that get exposed as field properties.

Here is an example for if i had a grid of Employees.

EmpMan is a BL Object.

PL.DBGridEmployees.Datasource = EmpMan.GetAllEmployees()

If i wanted a filter i would have to code another method. Internally GetAllOldEmployees might be calling GetAllEmployees and placing a filter on it?

PL.DBGridEmployees.Datasource = EmpMan.GetAllOldEmployees()

If i wanted to retreive the Name of a certain Employee i would have something like this.

EmpMan.EmployeeRecord.Load(EmpNo)
PL.TxtEmployeeName.text = EmpMan.EmployeeRecord.EmployeeName

Uptill know i only showed n:n requests - here is an example of n:m.

Database Structure = Emp n:m Addresses

EmpMan.EmployeeRecord.Load(EmpNo)
PL.TxtPostalStreet.text = EmpMan.EmployeeRecord.PostalStreet
PL.TxtPhysicalStreet.text = EmpMan.EmployeeRecord.PhysicalStreet

**In the above example the BL manipulates the data of the addresses to appear as if they are all in the same record. You can actual say that it denormalizes the data for the PL. When the PL has changed the data and saves it the BL has to send the data back to the DL that is normalized - Confusing!! **

**Lastly Never ever create methods with params to update the uderlying data as this BAD! BAD! BAD!. ** **Reasons: ** 1. It is easy to get errors this way. 2. It is difficult to maintain. 3. it is bad programming - not structured at all.

**Just Imagine ... **

EmpMan.CreateEmp(EmpNo, Name, Surname, TelWork, TelHome, .... - Ugly, very Ugly!!

Rather do it as shown below and let the Save method decide weather the record is new or existing.

EmpMan.EmployeeRecord.Property1 = Value1
EmpMan.EmployeeRecord.Property2 = Value2
EmpMan.EmployeeRecord.Save() 

I hope these example will help you.

Unfortunatly i found the BL is alot of hard work as all these methods and structures have to be coded by hand. You can try and generate these structures using some program but remember that the BL should be structured in the way that the PL requests it - not force the PL to be developed in a certain way. LLBLGen get's very close to almost replacing the BL but it is not there yet.

I have tried to show how i have seen this done, it is maybe not how it is suppose to be done but i have seen these methods used before and it is the methods that i find to work the best.

Let the force be with you.

Wayne

Thanks very much for the lengthly reply wayne - I really appreciate it!!

The code examples you gave illustrate exactly how you work with your business layers, and now I can see how we could work with that kind of business layer.

The difference between what you have and what I am considering, is that I seperate the actual "properties" of the business layer into a simple entity, and pass this to the UI. So in your PL you do this:

EmpMan.EmployeeRecord.Load(EmpNo) PL.TxtEmployeeName.text = EmpMan.EmployeeRecord.EmployeeName

And in my PL I do this:

entEmp = EmpMan.Load(EmpNo) entEmp.EmployeeName = "Bob" EmpMan.Save(entEmp) // To persist it

So, I actually have a manager class and a business entity object. The business entity is also denormalised in a similar way to yours.

I'm definately not suggesting that "my" way of having business entities seperate is a better way, to be honest I find your approach more logical. The reasons that I went this way in the first place are following Microsoft reccommentations. My main points of reference are the 2 microsoft "patterns and practices" for designing web app tiers, and for passing data between tiers:

http://msdn.microsoft.com/...AppArchCh2.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/boagag.asp

According to Microsoft, in my potentially distributed application, I should work in a more "document-orientated" rather than "object-oreientated" way. To do this, I should pass data between tiers, rather than expose is as properties of an existing tier. This is why we have our own "business entitiies", which are the method of commuinication between the BL and PL.

So - thats what I was thinking of when I came up with the design I was going to use.If I'm being honest I can see how yours is "nicer" to work with, and your approach seems to be more of an accepted approach than mine for LLBLGen users. Maybe I am placing too much emphasis on my microsoft references, what do you think?

As for your point about passiing params into "update" methods etc - hehehe, I know ezcxatly what you mean. You should take a look at some of the methods on our old app - ouch!

Again, I really really appreciate the effort you went to here

There are many ways to skin a cat....But the cat ends up skinned in the end. he! he! he!

Wayne

Hey guys I have been sitting in the background enjoying your conversations and now have a question.

So all of these extra tiers ...sounds like a bunch of more code to write... are you guys using LLBLGenPro to help write some of this code or is it all by hand?

I understand that the manager classes could be difficult to auto-generate as only the developer knows what different entities a specific manger must work with. But if a manager works with say 2 entities you still need to code all of the properties that match to the LLBLGenPro objects...how are you guys handling this?

Thanks Bert

Hi Bert

We use LLBLGen to generate the DL for us the rest is basically hard work like the PL.

I guess you can generate the BL if you had a certain formula on how to group your objects together but as i sayd before and i quote:

You can try and generate these structures using some program but remember that the BL should be structured in the way that the PL requests it - not force the PL to be developed in a certain way

Remember the idea is that you should be able to resuse the BL in more than one Application - for example you might have an Web App for customers and a back office system that runs on desktops applications. If you have webservices your webservices will also be working via the BL.

The DL's job is to present the data to the BL nothing more than that. The DL can't be doing the job of the BL because a BL might be making use of several DL's.

Wayne

wayne wrote:

The DL's job is to present the data to the BL nothing more than that. The DL can't be doing the job of the BL because a BL might be making use of several DL's.

Wayne

But I don't want to work that hard

I have been creating my BL objects which tie in several DLs. One of the things I do though is send back an entity collection (representing a single table) from the BL to the PL. I then bind it directly to an Infragistic grid.

This has been a tremendous time saver for simple maintenance table forms. Since, the database is updated without additionall code when I call the DataAccessAdapter's Save method.

Two questions. Is this the wrong approach?

And, how can I implement a method that creates an object that contains multiple llblgen entities as the direct underlying data source; thus, allowing me to bind and have the updating performed against the database?

Thanks,

I thought I'd offer my thoughts on design. I am trying to make the most of llblgen and keep my application as simple as possible. The adapter model has separate objects for doing the actual persistance (the entities cannot save themeselves) so the entities are already simple containers for data. I consider the entites to be part of the bl so I use them directly in the ui.

Since most of my work is done for me by llblgen, my bll can concentrate on applying business rules through validation and data retrieval. The ui I can instantiate an instance of an entity, populate it and pass it into my bl:

ProjectEntity project = new ProjectEntity();
project.Name = "some name";
project.Date = "5/20/2004"l
...
ProjectManager.Save(project);

The bl manager class validates the entity and persists it to the database. However, I haven't quite nailed down error handling. At the moment I'm raising an exception when the validation fails, but I might end up switching to a cusom error object. I haven't quite decided yet.

For retreiving multiple entities/rows of data, I standardized on returning datatables, since you can always return a datatable, but you can't always return en entity collection, I've chosen to keep things as standard as possible (using typedviews or storedprocedures return datatables) and give up a little conveinience. For returning a single entity/row, I return an entity directly to the ui.

Those are my thoughts anyway. I try to keep things simple and make the most of the tools I have

Interesting conversation indeed. I just want to throw my hat in the ring and share how I create my Business Facade Layers.

• I use high level use cases / usage scenarios to drive my facade objects
• Using the "Improving .NET Application Performance & Scalability" document (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/ScaleNet.asp) I try and make chunky interfaces, and not chatty ones.

So here is my latest problem and the solution will follow. Create an Accounting application that is responsible for account receivables and account payables for any company. Allow real-time and batch 3rd party data input from various billing systems (i.e. real estate billing, utility billing, personal property billing, etc.) as well as our own billing application. Allow real-time and batch data extract from various general ledger systems, (i.e. SAP, Oracle Financials, PeopleSoft, etc). Some clients prefer a thick client windows forms application and some clients prefer a thin client web based implementation. Consumers must be able to view their invoices online, receive their statements online, and pay their bill online.

Solution: Basically, I use the MSF to make this all happen, but here are the high points that take place in the development lifecycle.

• Define specific use cases & usage scenarios
• Refine use cases & usage scenarios into functional areas / objects
• Create a physical data model
• Code gen the DAL using LLBLGen
• Create a services / facade layer using step 2

Because some clients prefer thin client PL and some prefer thick client PL and some will be writing their own PL I need a solid facade / services layer.

My data looks like this: An account has customers, A customer has an address. An account has an address. An account has an owner. An account has invoices. Invoices have lines. Invoices have discount, penalty, interest, due date, etc. An account has payments. On and on and on.

I will typically write an AccountServices class that has an initilize method with many overlaods. I will also write other classes that make up all of the legos that relate to an account. In a nutshell, my AccountServices and other objects are initialized, they will call protected methods that initialize DatabaseSpecific object and expose these LLBLGen objects in their own properties. For example, when the accountServices.Initialize is called, the accountServices is filled with all of its related data and passed back to the client. AccountServices has all of the properties that it needs to make decisions internally and it also exposes what the client will need to drive its flow.

This approach avoids a chatty application, and the application is otherwise stateless. The PL can be anything because databinding is databinding, and no matter what the PL is, the facade objects always return information that is structured in the same fashion and structured for a usage scenario.

There is also granularity in the fact that if you need to dumb down code for webservices or remoting interfaces, you can do so by using a different starting point. For example, maybe you already know the invoice information and you dont care about the account. Well, an accountServices object exposes an invoiceServices object. So just initialize an invoiceServices object with the invoice information and you are off and running.

The only real problem is that, it is a real P.I.T.A to update data using a bound datagrid. So I dont implement updates and inserts in this fashion. I only use datagrids to navigate and select. I use a form or control to collect changes and submit them to the facade.

So, thats how I do it. Hopefully someone might find it useful. Sorry for the long read.

My answers to Fishy's questions.

I have been creating my BL objects which tie in several DLs. One of the things I do though is send back an entity collection (representing a single table) from the BL to the PL. I then bind it directly to an Infragistic grid.

This has been a tremendous time saver for simple maintenance table forms. Since, the database is updated without additionall code when I call the DataAccessAdapter's Save method.

Two questions. Is this the wrong approach?

By Passing a Collection back and working directly with it via a grid i asume that you are working with data that does not need to be validated or audited and does not need to go through some type of process.

If you are writing additional logic in your PL before or after calling the DataAccessAdapter's Save method to do any type of business logic i would say it is the wrong implementation of a BL.

In a good BL design your PL should never know about the DL.

We (I) also pass back Collections sometimes for display purposes but all updates happens through the BL. The BL then accesses th DL (LLBLGen Entities) and applies the update. In my previouse example in this thread is i had the following:

PL.DBGridEmployees.Datasource = EmpMan.GetAllEmployees()

This is a good example where our BL would return a collection, datatable or dataset that get's use for display purposes only. By returning a collection via the BL for display purposes that does not mean that the PL is dependant on the DL . The PL does not know that it is getting a LLBLGen Collection - it might as well be a dataset. So if we had to remove LLBLGen (God forbid!) our PL Should still function althought our BL would have to change.

And, how can I implement a method that creates an object that contains multiple llblgen entities as the direct underlying data source; thus, allowing me to bind and have the updating performed against the database?

Use a collection from the DL for display only when wanting to save changes from a grid instantiate a BLObject that updates the changes for you. This means that you must design your app to work with one record at a time.

Cadmium wrote:

The adapter model has separate objects for doing the actual persistance (the entities cannot save themeselves) so the entities are already simple containers for data. I consider the entites to be part of the bl so I use them directly in the ui.

This is not ideal because you can't replace the DL with something else thatn LLBLGen without doing mayor work on the PL aswell as the BL. We all know if the DL changes the BL is going to have to change aswell but that does not need to be true about the PL.

I also have to say that the implementation of a BL depends on the size and capable growth of your application. If it is a small app then you don't need to implement it. On bigger projects with large databases and many processes a BL is a must as it devines your rules for your application.

I have to sign of now. - Wife standing next to me - looking very upset.

Wayne

wayne wrote

This is not ideal because you can't replace the DL with something else thatn LLBLGen without doing mayor work on the PL aswell as the BL. We all know if the DL changes the BL is going to have to change aswell but that does not need to be true about the PL.

I disagree. The entities llblgenerates are about as generic as you can get, most of the entity is composed of 'TableEntity.Column'. You can't get more generic than that really. Yes, if you replace the dl there will be some small changes to the front end (using adapter entities), but it will be very minmal for a small-mid size application, and probably less work than writting a wraper for the dal up front.

Of course if changing your presentation layer is not an option, or you're application is huge that's a different story But I say let llblgen do as much work as possible when you can get away with it.

Great discussion, guys

I'm a little short on time so I can't really participate, I just want to thank you all for investing the time (and the risk to sleep on the couch ) to explain your visions. Keep up the good work and keep the insights coming!

Without going through the tedium of copying and pasting quote snippets:

Fishy: I think you can accomplish what you're trying to do while satsifying many of Wayne's objections (as well as staying relatively abstracted from the DL in use) by:

A: Using a hybrid of manager and domain models. Go ahead and put business logic in the entities themselves since the manager won't have the chance to protest when you want to save them (you're not calling manager.save(entitycollection) you're basically calling entitycollection.savemulti after the grid is done with it.

B: Just set up an extremely lightweight intermediary object for each entity that inherits directly from the LLBGenPro-generated entities and passes all properties, methods, etc directly to the caller - basically don't override any of the members. Also, set up an interface that all of your new inheriting entities implement. This way, the interface your PL/BL objects implement have nothing to do with LLBLGenPro. This keeps your abstraction level high with minimal muss and fuss (although, again, according to Frans this may not be necessary).

Now the frosting on this lovely cake comes in the form of the fact that just about everything in "B:" should be able to be generated by the LLBLGen template system, so any changes you make should be able to be re-generated by the LLBLGen system.

Clear as mud?

Jeff...

<EDIT 1> Cadmium: I think the problem is not so much of the constructiong of the entities being more or less generic, but the physical dependency the PL has on the LLBGen entities if they are what's used to pass data back and forth between the PL and BL. But, I agree - let the LLBLGen entities do all the work for you, that's why I think if you want the best of both worlds, just create a lightweight inheritance layer that decouples the PL from the LLBLGen stuff as I mentioned above...

<EDIT 2> Hmmm...who wants a separate forum to discuss these types of architectural questions? I personally very much enjoy them and have learned much just by reading everyone's responses. So? How 'bout it Frans? Mind setting up another forum for these types of "quasi-off-topic" issues?

I agree with Jeff on his last edit.

I think this thread and all the others that talk about construction of a BL with LLBLGen should have it's own forum inside Tinyforum and should not be under general as there has been alot of interest around this subject.

Please Frans..

I hope i am not the villain in this thread?

Wayne

I've created a new forum for this, 'Architecture'. Close your browser and re-connect to the forum. This thread will be moved tomorrow to that forum

A seperate "architecture" area in the forums gets my vote

Its interesting and really useful to see how people are designing their application tiers, especially the business layer and how it works with LLBLGEn.

Going back to the "use LLBLGen entities or write your own entities", this is a interesting topic for me. Since I want my business entities to model the process rather than a DB table, I want to write my own, so I can (as waynbe said earlier) "de-normalise" the data into an entity that works for the PL layer. My PL layer can then hapilly change properties in the entity in its flat state, and then pass this back to a "business component" once it is done.

As I metioned earlier in my reply to wayne, this is effectively the same as what wayne, jeff, and I think "devildog" are doing. The only difference is I am passing entitties, rather than exposing them as properties - although it seems I am in the minority for passing "entities" - this is starting to make me nervous!!

I have to agree with wayne in that using LLBLGen entities in the PL does make me slightly nervous, I would want the level of abstraction. But - to play devils advocate - maybe we're just going too far with the whole teir design? If what cadmium does works well for him, and he doesn't mind that the PL needs a reference to LLBLGen, then thats fine.....

Another good article I found for reference:

http://dotnetjunkies.com/WebLog/seichert/archive/2004/03/13/9030.aspx

Otis - you could make a fortune out of LLBLGen based architecture consultancy!!

maybe we're just going too far with the whole teir design?

It all depends on what you are trying to acheive!

Imagine you had to add Webservices to your architecture or you had to share some functionality of your BL with some 3rd party. If your BL is passing LLBLGen entities around it would mean that anybody that would like to use this extension would have to have a copy of your DL or atleast a reference to it. - This would realy scare me! As nothing will stop the 3rd party from skipping the BL and working directly with your DL.

The BL is suppose to hide the DL layer from the PL. - Abstraction Layer!

**Where is your Security now? **

Wayne

wayne wrote:

It all depends on what you are trying to acheive!

Absolutely. I was only suggesting that for simpler apps, this might be OK. Its def. not the way I would go for our app, I would want that layer of abstraction.

We have been moved.

Thanks Otis.

wayne wrote:

maybe we're just going too far with the whole teir design?

It all depends on what you are trying to acheive!

Imagine you had to add Webservices to your architecture or you had to share some functionality of your BL with some 3rd party. If your BL is passing LLBLGen entities around it would mean that anybody that would like to use this extension would have to have a copy of your DL or atleast a reference to it. - This would realy scare me! As nothing will stop the 3rd party from skipping the BL and working directly with your DL.

The BL is suppose to hide the DL layer from the PL. - Abstraction Layer!

**Where is your Security now? **

Wayne

If I'm using the Adapter then the Entity should have no access to the underlying data source.

I think for now the way I will approach this is to use a bit of a hybrid.

Always create a wrapper class to group the results of use cases & usage scenarios into functional areas / objects (as Devildog stated).

Expose properties that reflect Entities that may be bound to controls. Create and expose DataTables if I need to denormalize.

The class would be responsible for saving information (Domain model) but that may in-turn use another class, perhaps a helper class, to call DataAccessAdapter.

I would love to see some real examples of how this work. (any takers?)

Thanks,

How do you want see it?

A Visit in SA would be nice.

wayne wrote:

How do you want see it?

A Visit in SA would be nice.

Santa Ana? oh, South Africa, afraid my boss wouldn't go for that.

mmm, maybe Frans could devise a method to store / retrieve and catalog code snippets (albiet, could be complete apps )

Fishy - it sounds sensible to me what you are proposing doing!

I think some code examples on various approaches and their subtle differences would be a nice thing to have in future releases of LLBL documentation too.

Just a thought: Its interesting how MS seem to compleletely dismiss a OO way of working with business objects (e.g. a domain model). They don't give any real reasons for this, instead they just try to explain to us that we should all use a message based, "component" service model (i.e. don't expose properties, but pass data as params instead). I wonder why they don't seem to entertain this in their msdn patterns and documents, after all, its very similar at the end of the day, you could almost argue its just a matter of taste... I guess its because we seem to be heading towards a more distributed service-oriented environment, and by using service-oriented business objects its easier to expose them as services in the future if we need to. Not that it would be hard to add a business facade to "domain model" business objects that expose properties, it would just be an extra layer. Hmmmm.