Re: Best practice - Connected/Disconnected mode - and more
- From: "Cowboy \(Gregory A. Beamer\)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx>
- Date: Sat, 14 Jun 2008 10:37:12 -0500
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.
Typed dataset or not ?
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.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss
or just read it:
http://gregorybeamer.spaces.live.com/
********************************************
| Think outside the box! |
********************************************
"Gabriel" <nospam@xxxxxxxxxx> wrote in message news:e9pDQvhzIHA.3920@xxxxxxxxxxxxxxxxxxxxxxx
Hello,
I'm looking for documentation with "Best Practice" for ASP.NET application
In which case use Connected or Disconnected mode
Typed dataset or not ?
I didn'd find anything pertinent ....
If you have a good link you are welcome :)
Regards,
.
- References:
- Best practice - Connected/Disconnected mode - and more
- From: Gabriel
- Best practice - Connected/Disconnected mode - and more
- Prev by Date: Re: Inserting data
- Next by Date: ASP.NET vs Silverlight?
- Previous by thread: Best practice - Connected/Disconnected mode - and more
- Next by thread: Re: Best practice - Connected/Disconnected mode - and more
- Index(es):
Relevant Pages
|
Loading