Datasets (typed or not) take more memory. I can't give a solid number
because I have not run extended tests. However, it's obvious. Just
look at all the data that a dataset contains. First it contains all
the data you want, and this is good. Custom entities also contain that
data. The overhead comes with:
1) all the schema (table name, column names, column types, etc...)
2) multiple versions of the data (Current, Original, Proposed).
The architecture I proposed was designed partially for compiler and
intellisense support. The other layers of your application have full
intellisense support on business and data layer classes that interact
with the database. When a database entity changes, you only have one
line of code to update. If you forget, you get a runtime error that
explains exactly which field name was "missing" and on what procedure
or table.
As Nicholas said, you have multiple changes to make through your
application when the xsd regenerates the typed dataset. You now have
to change code in every class and method in your solution that uses
that dataset. Do you bind that dataset to the ui? Do you auto-generate
columns, or like most people do you like to rename the database columns
to a friendly user interface name. IE. "FirstName" to "First Name".
Then when you create a bound column, you are not using intellisense
everywhere. Instead you are typing a string value, which is not
checked until runtime.
Example of the invalid dataField in my aspx page:
<asp:BoundColumn Visible="False" DataField="FirstNM" HeaderText="First
Name"></asp:BoundColumn>
Runtime error:
"A field or property with the name 'FirstNM' was not found on the
selected datasource."
Silly me, the DBA renamed FirstNM to FirstName.
I have not used a typed dataset, anyone know if non-autogenerated
columns behave any differently?
When I bind custom entities to a grid, I use the same BoundColumns in
the aspx file. The difference is that the property name on the class
does not change when the database column changes, the data layer just
maps the new database entitiy name to the same old class property name.
Therefore the grid does not need to be changed. After all I always
want the same name, FirstName for my property. As a UI developer, I
could care less if the DBA decides to rename column FName to FirstName
to First_Name to FirstNM.
If you were starting from scratch, I would recommend the same solution
I gave above. But if you have alot of code written already, it may be
best to stick with what you have. That is what I am doing with the
example BoundColumn above. I wasn't given enough time for a rewrite.
From a practical point of view, you can't just refactor your entire
application everytime you find a different way to do something. You
can use new ideas in your next project.
Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/ 
