Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

How do you approach 3-tier in .NET?

Hello all,

  I'm just wondering what your approaches are when designing a 3-tier program in .NET.

  Do you prefer Typed DataSets to handle the moving the data around, and then a logic layer that runs logic on them?

  Or do you like objects such as "MusicCD : Product" with the logic methods right on the object?

  Just trying to get a feel of what other people are doing.  I am using datasets, and they are working just wonderfully...

Michael Giagnocavo
Thursday, September 19, 2002

I've been a developer on several projects using 3-tiered .NET architecture. My recommendation would be to use DataSet's as a transport mechanism because of the support inherent throughout the .NET framework.

For example:

- Windows Forms and ASP.Net user interface components work very well with DataSet's through use of data binding.

- DataSet's serialize very easily because they are XML underneath.

- The ADO.Net database support is very well integrated. Most of the time you can get away with not having to write code to map between databases and DataSet's.

Martin Fowler has written articles on design patterns which use DataSet's to implement 3-tier architectures.

Object-oriented developers are often resistant to DataSet's because they don't want to deal with relational data in their applications. Sometime in the future, Microsoft should be releasing tools that will let .NET developers deal with relational data in an object-oriented way. If you want to know more about this, check out ObjectSpaces. Note that the name is likely to change in the future.

Matt Kennedy
Thursday, September 19, 2002

You'll probably get your project done quicker if you stick to DataSets (typed or not).

While something like

MusicCD myMusicCD = new MusicCD();
myMusicCD.ProductName = "Backstreet Boys Greatest Hits";

might seem ideal, there's a whole lot of plumbing involved in making your own persistence system if the data is non-trivial.

.Net is very geared towards shuffling DataSets around. Go with the flow.

Luke Duff
Thursday, September 19, 2002

I'm looking forward to see what develops in terms of design patterns for enterprise-class implementations on the .NET architecture.

Based on years of experience with Java and J2EE, I know first hand there is tremendous power in the design patterns used with enterprise Java. It may be very easy to simply push DataSets around between clients, web pages and web services, but .NET really needs what Java has.

It would be worthwhile to see how well these patterns can be adapted to the ASP.NET and ADO.NET models.

Samuel Ford
Friday, September 20, 2002

This is what I read from the forum project on 

"There are two objects used for working with data in .NET:
DataReader - A firehose cursor (reads data row by row over an open connection)
DataSet - Reads all the data from the set and then disconnects.

Internally, a DataSet is populated by a DataReader. Thus a DataSet is only as fast as a DataReader and has additional overhead.

Determining which class to use depends on the application. For any data that cannot be used more than once, you should always use a DataReader. For data that can be reused, i.e. put in the ASP.NET cache or for data that needs to be serialized as XML, i.e. an ASP.NET Web Service response, you should use the DataSet.

As for why we populate specialized classes rather than handing back a reader or dataset to callers. This allows us to further abstract the data away from the application and provide friendly, type-safe classes -- example, the 'Post' class -- that developers use. They never ever need to understand the data tier if they do not wish to understand it.

As for contradicting messaging This is why we build these applications. It's important that developers such as yourselves get information direct from the source. Applications such as the ASP.NET Forums, Cassini, IBuySpy (and others in the works) demonstrate the best-practices as recommended by the ASP.NET team. "

Here is the thread: 


Sam Kennedy
Friday, September 20, 2002

I must admit, when I first looked at Datasets, I was disappointed: I thought here we go again, just passing data from the database to the client application, which will update it (without applying any business rules along the way!).  I then realised that the key to it is distinguishing between the two uses of Datasets.  The first is a read-only version, which is passed to the client to be displayed.  This is like the View in the MVC Pattern.  The client then builds an entirely different Dataset, which simply wraps up the parameters to be passed back to the server.  This is a bit like the Command Pattern.  I tend to build typed Datasets so that 'true' Properties are exposed, rather than having to use column names.

I am still experimenting with this approach, but I agree with previous contributors that Datasets are probably the best way of passing data around, because they simultaneously behave like recordsets and XML documents and therefore there is fantastic support for them within the .net framework.

Tim Riley
Tuesday, September 24, 2002

I would add to the DataReader vs DataSet discussion: Go for the DataSet whenever you do not have any performance issues. The DataSet is so much easier to populate using the DataAdapter. When you have a performance issue, and have a way to measure improvement, then is the time to experiment with the DataReader to see if it removes the bottleneck.

Thomas Eyde
Wednesday, October 02, 2002

*  Recent Topics

*  Fog Creek Home