IntraLayer Communication

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.

Answer this question

IntraLayer Communication

merc

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 :)
adarsh khare

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...
Terry Thrift
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.
AZ17
Thanks a lot for all your responses. I do know that given a choice custom entities are one of the best options for reasons such as
- 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.
IntraLayer Communication

Answer this question