Create new object properties based on datatable structure

  • Thread starter Thread starter Sergio Montero
  • Start date Start date
S

Sergio Montero

I have a MustInherits Base class that implements a custom IDataLayer
interfase. IDataLayer expose CRUD methods. Base class constructor requires
two parameters:
ConnectionString
TableName

Another assembly, sharing the root namespace, contains a set of Custom
attributes used to validate properties values, just like the Validation
Application Block.

Base class is compiled into an Assembly.
I'd like to be able to give Base class the ability to add itself a set of
properties that match a datatable structure once the constructor is executed
and also have the posibility to add a customattribute to any of these
properties.
The set of properties could be as diferent as the Tablename target changes.

I'd like programmers that consume Base class assembly could write less code
and need less database structure knowledge.

I've been Googling articles about IExtender, PropertyDescriptor and other
topics without have a clear idea to where to point all the effort.

Is, the scenario described, posible to achieve?
Could anybody point me to the rigth direction?

I'll appreciate any help.

T.I.A.

Sergio Montero
MX
 
If the goal is to write less code and nothing much else, you might be better
off by generating proper classes from tables / views / stored procedures
beforehand.

If you want to generate dynamically, you can do that:roughly like this
- get metadata from database for target table / view / sp
- generate code for a class in text file or stream exposing required or all
properties. You can set attributes here as needed
- compile the code using reflection or available compiler into assembly, for
example as .dll
- register dll and use it or load assembly and instantiate class
- provide class instance to consumer

Take a look at reflection namespace for details.

However, if you provide object like this, programmers will need reflection
too to detect which properties to use and what are types / names etc. It's
same stuff as "database structure knowledge" because they need to find out
what are the properties instead of table fields. I don't believe you'll save
much coding or investigations in this way. More likely whole contraption
will become less stable. If you think about it, it's same concept as using
raw data reader, where you can access collection of field or column names,
without knowing beforehand what are the fields / types. You can subclass
datareader or dataset / datatable exposing generic access property and
analyze for each call if custom attribute is applicable, but this doesn't
help in any way other people trying to use the class. Not really useful in
my opinion.

I would recommend to use some class generator and pre-create classes
beforehand. If db structure is changed frequently, you can put all
pre-generated classes in separate assembly to make upgrade process simpler.
Usually structure of db is pretty stable.
 
Yes it is possible (I have done it), but depending on your level of
experience you may wish to consider simply using a DataTable, and
dynamically adding columns. Personally I'm not a big fan of
DataTables.

To create dynamic properties, you need to know about the
component-model. But first: realise that (purely) dynamic properties
will *not* be avialable at compile time, but can be used for
data-binding. This means that it doesn't necessarily help devs much.
If you really want to generate programmable classes, then perhaps look
at other tools, such as sql-metal. I believe that you can use this to
generate simple classes from an existing database, but this will need
to be re-executed to adopt new changes. Equally, tools like
n-hibernate may have scope.

If you want mw to give an overview of dynamic properties via the
component-model, please say - but it is quite a large topic, and I
just want you to know that I'm not sure that it (by itself) will do
everything you want. However, the starting point is to understand
TypeDescriptionProvider (2.0) or ICustomTypeDescrptor (1.1 and 2.0)

Marc
 
Thanks Marc. I'll take your offer. Could you please share yoir knowledge
about how did you make possible what I'm trying to do?
I'm going to start reading about the topics you recommend. You did exactly
understand the point of what I need to do.
I'm aware that dynamics properties won't be able on design time and devs
would have to use Reflection, but I think that if I acomplish that, I'm
practically automating simple catalogs programming, just like a serial
production of programs.

TIA
Sergio
 
I'll pen something over the weekend (about to get train) - a minor
point, but technically this isn't reflection.

Mar
 
I got a deja-vu moment...

The following covers the basics of creating a property-bag
component-model implementation - but please read the rest of this post
before following:
http://tinyurl.com/3b6wxz

Note that this simplified example only covers a single Type; for a
more extensible framework you need more code. Note that known
properties also can be added at compile time, ideally also referencing
the property-bag so that everything is considered equal. However! You
would still need to add the properties at some point, so you'd also
need some code to discover the schema. Adding proper opportunity to
handle property changes (before they happen) adds more code.

If all you want is simple data storage, then in this instance I would
probably advise you to avoid complexity, and just use a DataTable.
This is a rarity for me - I don't normally suggest such.

Finally, if you have 3.0, you might also wish to note that this
includes an additional model for properties, used (as parallel
implementations IIRC) by WF and WPF. You might be able to trick these
into doing a lot of the above for you, but again - keep it simple ;-p

Marc
 
Back
Top