Typically
when passing data between various layers normally most recommend use of
custom entities because it allows the developer to write code which
gives finer control to the data. The other means could be usage of
dataset, typed dataset.
The way I look
at it, custom entities take time to code and at the same time one needs
to also write logic for retrieving data from database and looping
record per record into an array of custom entities.
The other way
is to use dataset directly. Normally when performance is considered,
people do tend to conclude that dataset is too heavy and typed dataset
is even the more heavier. Even though its easier to use and reduces
development time.
My query is
that even if I have a small web application that has about 10-15 pages,
would a typed dataset/dataset be a performance killer especially when
the user expects the page to come in 3-5 sec.
Would appreciate if anyone could share their thoughts on the same.

IntraLayer Communication
Bei
I am a big proponent of custom entities primarily becuase of the flexability they offer in terms of interoperability. If you have any plans/needs to ntegrate with non-.NET clients, datasets will cause lot of problems.
Based on the needs you listed (small site, limited users...sounds like 100% .NET solution), typed datasets will work fine.
If you have more complext requirements down the road, then a custom entity may make more sense...
DJPO
- Custom Entities are usually slim, from an XmlSerialization point of
view, and there are also tools, like System.Xml.Serialization
attributes, to make it even slimmer.
- Custom entities supply strong typing and more compact, faster objects.
- They are abstract enough to require no changes to the DAL if the underlying database schema changes
- Being custom classes, they enable you to incorporate information
aggregated from multiple sources and represent free-form and
hierarchical data.
- A custom class can be marked as serializable and serialized through any
super-optimized algorithm.
I guess everyone is aware of the advantages. What I was trying to get as is normally we end up with a small web development project, with 10-15 users, about 15-20 aspx page, 3-4 components and so on and timelines are very short, does it make sense then also to go in for custom entities.I mean, all said and done we would still end up with spending effort for writing lot of code. Top of that one would also need to write loops to put data return by SQL Server into arrays of custom entities as the format of both would be different.
Keeping all these efforts into mind I sometimes wonder how viable it is for a small size, small budget & smaller timeline project.
dbrich
Hi,
There seem to be alot of unknowns in your post to get a definitive answer (if there is one :P).
For instance how many people will be accessing those 10-15 pages. If you expect 1000 concurrent users then your design will need to be different than if you have 10.
Also is the data read-only. Will the user be required to fill in forms and submit data back to the server This will impact of how you design your layers, and control view state.
Suggested reading:
http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnpag/html/scalenet.asp
http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/
Also you mention "Typically when passing data between various layers normally most recommend use of custom entities because it allows the developer to write code which gives finer control to the data."
I don't know if is the case. Perhaps recommended by developers with a dislike for datasets :P Each have their pros and cons and it's the Architects job to know when and where to use either. Having said that with Generics and .NET 2.0 datasets become a smaller player :)
Tor I
Hello,
we have used all the solutions you mention in our projects. DataSets, TypedDataSets, and custom entity classes. My current prefered option is to forget the datasets and go for custom entity classes produced by code-generation (using tools like My Generation or Code Smith). Almost as simple as TDS's class generation.
And now (w/ .net 2.0) you can do Object Binding for presentation if you want, so it seems to me to be a simpler decision. There are very interesting uses for data sets, but (and this is a personal opinion) I think they are more useful in winform applications.
Appart from this, if you are doing any kind of interop stuff, you have to keep in mind that DS's "don't go through" web services in other technology worlds, they are not interoperable.
Just some notes.