Hi,

I just wanted to check something with you all:

I have (as some of you know), a PL, a BL, and the DL (LLBLGen-generated). Right, I now need to create some code to populate a navigation "tree" - the tree can have upto 3 layers. To do this, I need to add code get a couple of collections, check various values, and also recurse. The problem is I am finding my architecture slightly restrictive, which makes alarm bells ring!!!

To expand: I can't add this code to the BLL, because it (the code) is concerned with populating a nav tree. So, I have to add it to my nav page code behind. But the code behind here needs to get the various bits of data in order to work, so I need to add some methods to my BL like "GetArea" and GetChildAreas", so that the data is available for my PL.

It all works, but my ideal solution (which I cant do) would have been to create a method to populate the nav bar - this method would have gone thorugh to my DL to get the data it needs (thus not needing constant calls to the BL), and would be somewhere I could reuse it maybe in the future.... but where would it be!?!?!!?

What do people think? Holes in my architecture? Or is it just the solution to this specific problem? Or am I being too obsessive about this

Eagerly awaiting feedback!

MattWoberts wrote:

Hi,

I just wanted to check something with you all:

I have (as some of you know), a PL, a BL, and the DL (LLBLGen-generated). Right, I now need to create some code to populate a navigation "tree" - the tree can have upto 3 layers. To do this, I need to add code get a couple of collections, check various values, and also recurse. The problem is I am finding my architecture slightly restrictive, which makes alarm bells ring!!!

To expand: I can't add this code to the BLL, because it (the code) is concerned with populating a nav tree. So, I have to add it to my nav page code behind. But the code behind here needs to get the various bits of data in order to work, so I need to add some methods to my BL like "GetArea" and GetChildAreas", so that the data is available for my PL.

It all works, but my ideal solution (which I cant do) would have been to create a method to populate the nav bar - this method would have gone thorugh to my DL to get the data it needs (thus not needing constant calls to the BL), and would be somewhere I could reuse it maybe in the future.... but where would it be!?!?!!?

What do people think? Holes in my architecture? Or is it just the solution to this specific problem? Or am I being too obsessive about this

Eagerly awaiting feedback!

Since the data needed to populate the tree is necessary for any presentation mechanism (I assume) it stands to reason that you should provide the data in your business layer. However, since you're formatting the data for presentation in a tree do not tailor the BL call to return data in the exact format you need. If at all possible provide methods to get the data, just don't format it at the BL.

Now, you'll need to decide whether it's worth the extra clocks to retrieve a generic data source from your BL then reformat it instead of going to the source to get a TypedView/List. If there isn't a decent chance you're going to be swapping out or messing with the PL, maybe it's better to set the BL to provide the data in the format you need - especially if performance is a concern in this module. You're the only one who can decide whether it's important to break the rules in this case or not.

Also, the functionality Frans is putting into the next release (ResultsetFields) may help you here. When the functionality is in the framework you'll be able to specifiy all the fields you need from any/all tables in your database, specify the relationships to use, then pass it to your BL which will return the data in the format your PL requests. The best of all things! This way your BL remains presentation agnostic and you still get the performance benefit of a native SQL call with interchangeable presentation layers...

Bless you, Frans.

Jeff...

Thanks for that Jeff.

Mulling this over some more, its actually quite difficult for the BL to return this in the format I want, so I think that I may be better off wth the code behind making calls to "non-specific" BL methods as you suggest.

jeffreygg wrote:

Also, the functionality Frans is putting into the next release (ResultsetFields) may help you here. When the functionality is in the framework you'll be able to specifiy all the fields you need from any/all tables in your database, specify the relationships to use, then pass it to your BL which will return the data in the format your PL requests. The best of all things! This way your BL remains presentation agnostic and you still get the performance benefit of a native SQL call with interchangeable presentation layers...

Sounds good! So, a "ResutsetFields" sounds to me like a dynamically created typed view - created programatically rather than through the designer - am I on the right track? If so that does sound good!

Thanks Jeff!

Matt, you probably would like to take a look at the code examples I've posted in the runtime upgrades thread in the announcements forum

MattWoberts wrote:

Sounds good! So, a "ResutsetFields" sounds to me like a dynamically created typed view - created programatically rather than through the designer - am I on the right track? If so that does sound good!

That's exactly what it is. Although not strongly typed as I had mentioned in a different thread (that would be a trick!).

Jeff...

MattWoberts wrote:

It all works, but my ideal solution (which I cant do) would have been to create a method to populate the nav bar - this method would have gone thorugh to my DL to get the data it needs (thus not needing constant calls to the BL), and would be somewhere I could reuse it maybe in the future.... but where would it be!?!?!!?

What I have done is created a seperate project called GUIHelper in it I have various Shared functions that, for example, return an Infragistics ValueList. The function retrieves the data from the bl and then I just use the ValueList in a grid or combobox.

Fishy:

I'm populating an Infragistics WebList control - I thought about the extra class, although I was thinking about a creating a whole new layer - a presentation logic layer - but I dont think I would need this elsewhere very often.

Anyway, thats another interesting solution to consider - I'm off to look at These code examples of Frans now...