How should the database logic be stored in a website?

Question

I'm new to web development and am making a mini project on a simple social networking site.

I'm using ASP.NET with C# & SQL Server 2008 Express.

I've read articles on how one should aim to create a data access layer (DAL) for the database to be used. One method is to create strongly typed datasets & adapters via the designer tools provided by Visual Web Developer.

So, I've created this strongly typed stuff, so this is my DAL. I've also read articles on having a Business Logic Layer(BLL), but for this project, I want to forgo this layer and work directly with the DAL through my website code.

Then, I've read about how it's not wise to store datasets in Session variables. My first impressions were that, after login, I could create an instance of my strongly typed dataset, populate it, then store it in a session object for use across various pages.

So, how should I go about it? Should I create and populate my dataset instance on each page access? Should I call Update() on each page exit?

Pardon me if I look like I'm feeling around in the dark, but I am confused... even after lots of searching.

EDIT: For those interested in details, I posted a comment, but decided to include it here as well:

But this is a relatively tiny website. Registration, login, friends invitation & friends list, friend messages, profile pages. That's all. Also, this is going to be the only website I develop for a long while which is why I don't want to get TOO caught up in awesome practices

Answer 1

If you build a business layer, you will not repeat code (business logic) everywhere in the code. If you end up directly invoking DAL from your pages, you might end up having chunks of same logic repeated everywhere in the app, and with a maintenance nightmare.

I don't know how complex is your app, but having business layer makes sense in most cases.

Let your business layer take care of updating your data, expose methods which can then be invoked by your pages.

If you need to explore more, look into a principle called "High-Cohesion and Low Coupling"

Answer 2

You should be as stateless as possible. Storing a lot of stuff in the session harms your website performance and scalability.

Maybe if you could give us a concrete example we could give you more information about a possible solution?

Anyways, try reading this on your free time, it's an interesting and language agnostic (though its examples are in java and c#) view of software architecture:

Answer 3

Well you might be interested in reading these articles: http://www.asp.net/web-forms/data. Personally I hardly use Datasets anymore but rather use the Repository pattern in combination with custom objects (domain model) and use an ORM for the database-object mapping (with Linq to Sql, Entity Framework or NHibernate).

Storing much data in Session is not really done. I suggest you only store small amounts of data in Session and all things that are common for all users in the Cache object.

I also suggest to you to read the book Domain driven design:tackling complexity in the heart of software By Eric Evans.