Do not think of CodeBehind as a file, or you're already in trouble. It isn't
a "file" to your application. It is a class definition. It is the class
definition for a given Page. The class definition is simply split into a
Template (.aspx) and a class definition.
A Page is a System.Web.UI class, which means that it is a User Interface. As
such, it isn't a good idea to put much (if any) business logic into it. Your
business logic should reside in Business classes, classes that work with
data and have no User Interface. The Page is then the User Interface, with
all the User Interface elements in it, and the only logic in the Page should
deal with presenting the data from the data classes in the page, and
allowing the User to interact with it. The Page should interact with the
business objects via the business class programming interface.
--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
"Chris Kettenbach" <ch***@piasd.org> wrote in message
news:qh*******************@newssvr13.news.prodigy. com...
Hi I am designing an ASP.net app. Just wanted some opinions on code
behind options. My idea is to have a code behind file that the controls will
reference and have ascx files for the controls. Then have the aspx pages
call the controls. Is this a good approach? I wanted to throw all my
business logic in to the code behind file and then on the aspx pages that
use the controls just refernce the ascx files. Is this the correct
approach? Should I bypass the ascx controls if they are not fancy
customer controls just like a datagrid? Also I connect to SQL back end in the app
and get different data for some of the datagrids that will be on the main
page? Is it better to put the ADO.net connection logic in to the ascx
files? or better to use the Code Behind? Thanks for any opinions.
Regards,
Chris
