In ASP.NET 2.0, is there a way to reference a page control from a business object method, for example by accessing a "Pages" collection and use a construct like the below to access an individual page, control, and property?

Imports SomeNameSpaceFor.PagesCollection
Class TestClass
Sub TestSub
PagesCollection("NameOfTargetPage").NameOfTargetCo ntrol.NameOfControlProperty = whatevervalue
End Sub
End Class

A page event would have initiated the object's method, so the page would be "live". I'd like to do this in a way that doesn't involve passing the control to the method through a method variable.

If not the above approach, is there a different way to reference a page control from a business object method?

Thanks!

Hi there,

You can have your business method accept a parameter of type System.Web.UI.Page. Then you pass Me (or this in C#) to the business method in your page. E.g.:

Dim myTestClass As New TestClass()
myTestClass.TestSub(Me)

Then in TestSub you have access to that specific page that called the Sub.

However, this might defeat the purpose of the Business Layer. First of all, you tie it to a web app so you can't reuse it in, say, a Windows Forms app anymore.

Secondly, the TestSub won't know what Page you're passing in, so there is no guarantee that the controls you try to access really exist.

What's the reason you need access to the Page from within the business layer?

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Thanks for your reply. Those are useful points to consider.

Actually, I'm very much interested in keeping the business layer separate from the presentation layer. By way of context, I've been doing systems work for a while, though I'm new to ASP.NET (and VB.Net); my most recent experience is in Access VBA, so I'm translating those metaphors into ASP.NET/VB.NET (and finding lots of new things to learn). In Access, I could "reach into" a form control at anytime (though still through a "form controlling" custom class).

More background: the app I'm working on is like a highly structure "live" classroom session. So it's different from a web-site in the sense that the "state" of the user/program is not in the user knowing what he/she wants to find. The "state" is very much in the program, knowing (and telling) the user what they should do next. (And it's in ASP.NET because there could be last minute invitations to users who could not be required to do client downloads).

Because of that, there are numerous situations in the flow of the user session where the program will do redirections and modifications of the user pages, based as much on state information as on user requests.

Since I haven't programmed in this environment before, I'm going through a learning curve in terms of figuring out how to distribute the logic. My initial approach was to keep the pages as "dumb" as possible. The "page logic" would not be so much in the business layer proper as in custom modules that are between the business layer and the page code behind modules.

Getting a little further into it, I can see that I should probably be treating the code behind as this "presentation control layer" (which is no doubt it's exact purpose!), which will be unique to this environment in any case. And I'm thinking perhaps what I should be doing is using the business layer to make big decisions like "based on user action + state, this is what the user should see/do next". The result of that decision could be stored somewhere (maybe main cache), and then the page (code behind) could (during the response cycle), lookup that state and then say "based on this state, I should reconfigure myself (show/hide enable/disable controls, etc) in such and such a way."

Having written all this out, I can see that I need to learn more about the page request/return cycle, and the use of session, application and main cache, in order to find the best distribution of the code. I've got Beginning and Professional ASP.NET books from Wrox, but I'm having trouble finding an overview of the architectural scheme (page cycle,session and application state, inter-reference-ability of page/code-behind/custom class logic and variables, etc.) that I would like to have in order to decide how to organize the code. Several questions like "can I get at session cache from within custom classes?" come to mind.

Any suggestions on where I might get a better view of the big picture would be appreciated (could be in the books and I'm missing it!); also any suggestions on the basic approach I should be taking in terms of the general situation described above.

At any rate, it's been useful to write it out, so thanks!

The problem with Access is that everything is contained in a single application / executable. So, it doesn't really matter where you store what code. Obviously, a clean separation of presentation, business logic and data access is still possible, but it's unlikely you'll take a piece of Access code, wrap it up and reuse it in a Web application.

.NET, on the other hand, allows (and promotes) to do just that. You could write a Data Access layer and use it in a web service, web site, desktop app, Windows service and so on without a problem. The same applies to business logic. What starts as a Desktop app might grow into a web app tomorrow, or the other way around. By having a clear distinction between presentation (web versus Windows forms) and business logic (class libraries that don't depend on presentation elements like controls, forms and so on) you can easily reuse the same business layer in multiple type of applications.

Your assumption about the Code Behind and "presentation control layer" is correct. Something like would certainly make sense: The same code could be reuse in a Web App: Obviously, this is just pseudo code, but I am sure you get the idea. The business layer just returns information; in this case it returns a boolean indicating whether the Login succeeded or not. However, you could also return custom objects (a User or a Customer or an Order and so on) that provide more details for decision making in the presentation control layer.

The Wrox books you have should give you enough information to begin to understand the whole situation. The problem may be that it's all so large, that even though the information is right in front of you, you may not see it yet. I found that if I reread books after a while, some stuff starts to make a lot more sense.

In addition to these great Wrox books, you may also consider this book: Developing Microsoft ASP.NET Server Controls and Components. It's definitely not a beginners book, and doesn't give answers to all your questions. However, it does give an amazing insight in the ASP.NET Framework and its controls. Since controls are a vital part of ASP.NET, a good understanding of them really helps. However, maybe you should stick to the ones you have for now; experiment with .NET, build little sample projects, then tie them together in something larger. Once you get the hand of it, dig deeper into some specific topics.

Does this help?

<shameless plug>

I just finished writing a new book about ASP.NET 2.0. Instead of presenting little snippets of code for many features of .NET, the book features 12 working real-world applications with complete source code. Each app has its own chapter that fully describes architecture, class design, separation between layers and so on. It may give you some ideas about how to set up larger, real world applications. It's not out yet, and it's also not on this P2P Wrox site, but there is some information about it on Amazon.com and the Wiley web site in case you want to keep an eye on it: http://eu.wiley.com/WileyCDA/WileyTi...471749516.html

</shameless plug>

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Imar,

Thanks for the input. It helps my learning curve a lot to get these broad views and at the same time run into the technical constraints. Since my last post, I recognized that the real issue is that all "display" output is highly dependent on the physical/logical machine environment. SQL can be pointed at lots of different harddrives, and you can count on an RDBMS of some kind being in between. There is not such a standard (in practical terms) for UI, except Browser/HTML/HTTP/TCP/IP, which, as the existence of ASP.NET demonstrates, is highly limited. So if extended UI functionality is desired, there will always be a not-so-easily-migratable investment in the specific "UI machine", which for ASP.NET means code-behind. However, once I understood that, I relaxed. There are plenty of mechanisms for communicating between the code-behind and business objects...and there's no point in trying to control the "Forms" from the business objects, because the "Forms" are going to be environment specific anyway.

As for your shameless self-promotion, congratulations! I'll take a look for it the next time I'm at the bookstore.

Thanks again!

Yeah, I think you're seeing things the right way.

No matter how hard you try, you'll never be able to write UI independent code. You'd probably waste loads of time trying to create super generic stuff that, in the end, wouldn't work anyway.

However, with a properly designed business and data access layer, the code in the presentation can be minimized, so a move to a different UI might mean less changes.

Wrox used to have a book called "Professional Design Patterns - Building Adaptable Applications" that deals with this topic by examining and explaining proper design patters. Quite an interesting read, although it may be a bit difficult if you're really new to .NET. Not sure if it's still owned by Wrox; if not, I am sure you'll find it on the Apress site or otherwise at Amazon...

Cheers,

Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Thanks for the response. I saw that book title before, and it looked interesting. Maybe I'll track it down. Right now, I'm working my way through master pages, css, dynamic content...

Have a good one!