Design pattern for simple asp.net apps with business logic?

Question

I'm new to the asp.net world coming from windows programming. The sessions, authentications, page life cycles are still somewhat confusing concepts to me.

I am currently designing a simple website just to learn asp.net. (very simple discussion board w/ tags, sort of like stackoverflow but 100x simpler)

I have designed the data access layer and now on to the business logic. My Business logic looks like the following:

• Backend components: normalizing data, complicated calcultions etc. My backend only has 2 classes and maybe 15~20 members in total.
• A Controller static class for frontend classes to access.

My question are:

• Is the controller class nessasary? Should I instantiate each backend component directly in asp.net pages?
• Who commonly handles sessions and authentications? Should the backend take care of that or should a manager class in the front end be in charge of all the user sessions/authentications?
• I understand each visit to page the the webpage object is re-instantiated, is it really a bad practice if the front-end controls the back end?

Answer 1

1. Is this ASP.NET web forms, or MVC? MVC relies on controllers to serve requests, but if you built a controller class for web forms, it really depends on what the controller is doing and its purpose.
2. ASP.NET natively handles session using the Session property on the page, or the httpcontext (as in HttpContext.Current.Session). It depends on what you consider "Session", as this can have several meanings. Authentication can be handled by the Membership API very easily (read more about it online).
3. Not a bad practice in theory, but may be in implementation depending on how its designed. Certain objects can also be stored at a static level too, if they are meant to exist once per all requests.