In many ways, this is like asking: Which is better, a hammer or a
screwdriver?
It really depends on your goals. Let me give a what if. Suppose you want the
highest performing application. It is going to be a monolithic application
where all of the code is in a single executable. It will also likely be in
assembly code of some sort or at the very least some lower level language
like C. The reason is you do not want anything more than one executable is
you do not want to take any chances of marshalling across any boundaries.
Now, there are times you need this application. But, in most cases, you have
to trade off some of this performance for things like maintainability,
scalability, etc.
In which case use Connected or Disconnected mode
In general, you will want to build software as a service. The implication
here is your data layer is considered a service that your business layer
uses. Your business layer is a service your UI works with. I say works with
here, as we are moving more towards MVC and MVP type of patterns in this
space. This means the controller marries pieces and not an ASPX page. While
the difference is subtle in some ways, it is radical in others.
Taking this model, it makes sense that data is portable. It cannot be easily
portable if you are connected to the source all of the time. Now, what you
choose to use for portability is up for grabs. The trend is towards custom
objects, but custom objects have a downside of potentially being coupled
tightly to your data model. This leads people to ORM tools, of which LINQ is
not one, no matter what people sell it at (LINQ is ORM-like in many ways,
thus the confusion). THe push to ORM is so you can regenerate your objects
when business changes without having to resort to a lot of recoding.
But, you might decide that a DataSet is fine as a custom object. It is
deconstructable into individual objects, so this is not necessarily a bad
thing.
What is important here is you really cannot stay connected all the time.
First, it requires that you maintain a connection to a database, which is an
expensive resource to remain connected to. This is due to many factors,
including the memory on the database server (and web server) to maintain the
connection, as well as the expense of locking, etc.
The biggest benefit of being strongly typed is finding out you have a
problem at design time rather than run time. Depending on what resources
your company has devoted to testing, this can be critical to a good
application. Does this mean a strongly typed Dataset? Not necessarily, as
business objects are also "strongly typed". In many circles, the move is
away from strongly typed datasets to LINQ, but this is a good strategy, long
term, if you are flipping from the anonymous types to actual business
objects, especially if you are moving objects across class boundaries.
Hope this helps clear up the mud a bit.
