Here's some code in my BLL to retrieve a PO

        
public POEntity GetPO(int PONumber)
        {
            POEntity po = new POEntity(PONumber);
            // set prefetch paths
            IPrefetchPath2 prefetchPath = new PrefetchPath2((int)EntityType.POEntity);
            prefetchPath.Add(POEntity.PrefetchPathCreatedBy);
            prefetchPath.Add(POEntity.PrefetchPathPODetail);
            prefetchPath.Add(POEntity.PrefetchPathPOApprovals).SubPath.Add(POApprovalEntity.PrefetchPathPerson);
            adapter.FetchEntity(po, prefetchPath);
            return po;
        }

Ain't that purty?

Today I realized I needed something in the GUI that comes from the vendor table. So, yep, it's time to modify my POManager class again. I will add a prefetch for the vendor table so I can get the vendor name from my po object.

I do this over and over. I find I need something else in the GUI and go back and modify the BLL to give it to me. Of course, it's code I would have to write somewhere, but I'm just wondering if there should be/can be a better semantic decoupling of my presentation and business logic layers? Does anyone else have any philosophical observations about this? Is anybody else working on Sunday? I gots to know.

I think your on the right track. Some will say that you should not send an entity collection back to the gui but instead send a custom collection or arraylist or something else but I think it is acceptable if you are using the adapter model.

Your bll is bound to change based on the requirements of the gui. As long as you don't send gui components to the bll then your bll is flexable. I normally create helper classes for the gui to tie in the bll and gui components.

IMHO, you can overcomplicate your life with unneccesary layers or collection classes that don't buy you anything.

Take care,

Fishy

Is this object being edited on the UI in this scenario? Whenever I need to display data that is read-only, that involved multiple joins, I go ahead and create a sql view object. Then, all you have to do is modify the view and re-gen your code.

If you wanted, you could get a little wild and crazy and put all your pre-fetch paths in your app.config for each manager, and build it dynamically.

Hi,

For web application, I just came accorss this link. It is really great way to saperate business layer and GUI. http://www.sitepoint.com/print/xmlxslt-driven-website-net

Does anyone know similar way for Network Application design, where developers bind XML data to GUI and really flexible?

Regards,

Developer

You could create an object that exposed an IPrefetchPath member, then modify this objects prefetch path member as needed, then pass the object to the GetPO method, and use the objects prefetch path member instead of encapsulatiing the prefetch path in the GetPO method.

As it stands now, if the GetPO method is in the BLL then it appears to be completely decoupled from the GUI.

Lets say that you find this approach somewhat appealing, you could create a series of overloaded constructors that the caller could use when creating this object that would initialize the object with "defaul sets" of predefined prefetch paths and then maybe a constructor that uses a parameter array so the creator could get totally crazy and specify as many prefetch objects as they wanted at instatiation time.

You could also create an overload of the GetPO method that would accept additional pf path objects that would be appended to the already encapsulate prefetch path object. That way you could simply just make the change on the client and be done with the change, because chances are that you had to change the client anyway.

Does this make sense or am I missing the question?

Yeah you're right, I could make the my "BLL API" more flexible so that there is less chance I would need to change it when the GUI needs something else. Of course it's a tradeoff, trying to do more work upfront in anticipation of saving time making more changes later. I think it's a basic paradox of doing middle tiers, that in theory they should be ignorant of the upper layers, but...they must provide everything the higher layer needs, so their design is in fact driven precisely by that.

Well, chances are youll never be able to totally plan for everything up front. But, now that you have identified a change in requirements, chances are, it will chanage again at some point. So you could simply take the refactor as you go approach and create the more flexible method while you have the time.

Typically, I try to keep a very loose coupling between objects and try to minimize the places that things need to change when the requirements do (because they always do.)