Tables != Classes

Erik fights for the removal of [TableName] from primarykey-names and sets an equal sign between Table and Class.

His point about the ID field seems ok, but as I see it, this all boils down to setting a standard and keeping it. In my opinion the naming in the database is somewhat irrelevant because I usually like to have alternate propertynames in my code anyways. For example I always use codegen attributes with my typed datasets to prefix all columnnames with "Item" so that they appear consequetively in Intellisense (sucks to skim through all the elements for the DataRow to find the column named "Size"). Using codegen attributes for the columnnames also makes the code more resilient for database changes, and enables Erik to change "CustomerID" to "ID" in the database without any implications for the code other than a simple change in the XSD.

With regards to the dataset/datatable and OOP I feel that setting Table = Class is a dangerous simplification. A table or tables might often map directly to the Table Module [Fowler] pattern as a dataset, but in some cases Data Transfer Object [Fowler] constructed from database information (as a Custom Business Entity [MS Data Application Block] ) might be a better solution than Table Module. In .NET however, because of the serialization capabilities of the dataset, the Table Module works great as Data Transfer Object. Unless the structure is too large or complex that is.

If you're working with software reengineering Table Module usually becomes completely impossible when you have to handle old, patched and poorly formed database-structures and you have to abstract the Tables.

Constructing a class that is similar to a well-formed table as a Data Transfer Object makes sense in most green-field scenarios. This is because you get to define a comfortable table structure from day one, and the typed dataset that makes implementing Table Module a breeze. But saying that a Table is the same as a Class is too easy and removes the careful consideration that should be done when architecting an application.

4 Comments

  • This is the reason why Martin Fowler is not the best person to listen to. An 'entity' as conceptual item resolves to a table. See E/R model, NIAM/ORM model.



    Working with entities in code, you can easily map a table to a class. To FILL it you can use a data transfer object. However that's just to transfer data, not the entity itself.

  • To clarify; the term Business Entity is used by Microsoft, not Fowler. And yes, of course you can map a table to a class (ref. Table Module). This is filled by a DTO, but with the dataset xml serialization it becomes both the Table Module and DTO.

  • The only problem i found using codegen attributes on the XSD to generate custom property names on the DataSet class is when you expose those DataSets in a WebService.

    The WSLD file generated does not have those codegen attributes so the class created on the client is different. :S

  • Not very important I guess, but I see DataSet more as Recordset pattern in Fowler's PoEAA and the Table Module pattern typically uses Recordset pattern.



    It would be interesting to hear Frans elaborate about that an 'entity' resolves to a table. I'm afraid I don't follow.

    :-)



    Best Regards,

    Jimmy

    ###

Comments have been disabled for this content.