471,337 Members | 1,133 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,337 software developers and data experts.

Constants for DB Fields in Front End a good idea?

Was wondering if anyone uses constants for field names coming from the
db stored procedure whihc return the query result? If the field name in
the DB changes, it surely helps but the work around I usually use is
the alias in the query? Any suggestions or idea?

Thanks.
-OMD

Feb 10 '06 #1
4 1408
I store database procedure names, parameter names, and result set
column names in a mapping file. I keep a separate mapping file for
each table. I also create a data factory for each table.

See an example of my mapping files here:
http://www.xquisoft.com/xqsdn/docume...taFactory.html

Then I can use intellisense in the factory class to use the mapped
entities. The code example above uses an open source component that
you can find here:
http://sourceforge.net/projects/xqs-data/

Michael Lang
XQuiSoft LLC
http://www.xquisoft.com/

Feb 10 '06 #2
OMD,

Actually, I prefer to use a typed dataset if possible, so that I have
compiler support for fields on the table.

If your design doesn't warrant the use of a typed dataset for the result
set, then I would go with the constants. With constants, if you make a
change in the SP in the data it returns, you just change the constant in
your code and recompile.

With typed data sets, you have to actually refactor your code everywhere
so that you use the new field name, since the property exposed will be with
the new field name (once you regenerate your typed data set in response to
the change in the SP).

It's a trade off, really, as you get the safety of the compiler with
typed data sets, whereas with a constant, if the constant is wrong, then you
can get an error at run time.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"OldMacDonald" <ra*******@softhome.net> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Was wondering if anyone uses constants for field names coming from the
db stored procedure whihc return the query result? If the field name in
the DB changes, it surely helps but the work around I usually use is
the alias in the query? Any suggestions or idea?

Thanks.
-OMD

Feb 10 '06 #3
Thanks Nickolas & Mike. I am using XSD's in my project but refactoring
is a bit of pain. What would be the overhead of using constants or
IDataFactory Interface on the performance compared to the hard coding...

Feb 10 '06 #4
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/

Feb 14 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by William Ryan | last post: by
1 post views Thread by SerGioGio | last post: by
3 posts views Thread by rdemyan via AccessMonster.com | last post: by
34 posts views Thread by newsposter0123 | last post: by
3 posts views Thread by rdemyan via AccessMonster.com | last post: by
17 posts views Thread by Neil Cerutti | last post: by
12 posts views Thread by Gordon | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.