Attention: We are retiring the ASP.NET Community Blogs. Learn more >

DataSets and Table Module

There seems to be some confusion between DataSets and the Table Module Fowler PoEAA's pattern.

Fowler says a Table Module organizes domain logic with one class per table. Then he says that "the primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order, while a Table Module will have one object to handle all orders", and that a single instance of a class contains the various procedures that will act on the data.

Fowler suggests that you could use a DataSet (RecordSet in his book) when you are using a Table Module, but that does not mean that every time you use a DataSet you are using Table Module, or that if you use custom classes you are not using Table Module. A lot of O/R mappers use Table Module with custom classes.

Lets see how we use DataSets in DeKlarit:

  • One DataSet has more than one DataTable, with relations between them. For example, a master-detail relation.
  • One DataSet usually has a specific instance of the data, for example, one Order, with header and lines. You can also have all the Orders and use them the way Fowler suggests, but it is used in the same scenario where in a domain model you have a collection of instances (like a CustomerCollection).
  • Each DataTable in the DataSet does not map to a database table. For example, in the Order header I can have the Customer Name, so it maps to a join between Orders and Customers. In the Order details I can have the Product Description, the Product Price, so it maps to a Join between Orders Details and Products. The mapping between the DataSet and the real database tables is done by DeKlarit, and if a databse schema change implies a change in the way it should map it, DeKlarit will regenerate the corresponding code.
  • You can have a complex process model that uses each DataSet. You usually dont have all the methods in one class, even if in DeKlarit there is a lot of logic running in the adapter, as you can add adding declarative rules to your entity and those business rules are triggered by the adapter when you try to persist the changes, 

This approach does not follow any of the Table Module rules. There isnt a table per class, not all the data is loaded in the DataSet, and the logic is wherever you want.

So, DataSet != Table Module. The DataSet is just a standard interface to represent data that provides, for free, most of the things you could want to do with data. You can use it in any way you want.

 

4 Comments

  • "Each DataTable in the DataSet does not map to a database table. For example, in the Order header I can have the Customer Name, so it maps to a join between Orders and Customers. In the Order details I can have the Product Description, the Product Price, so it maps to a Join between Orders Details and Products. The mapping between the DataSet and the real database tables is done by DeKlarit, and if a databse schema change implies a change in the way it should map it, DeKlarit will regenerate the corresponding code. "


    Interesting. Say, I add a row to that dataset. How is DeKlarit gonna add a new Customer row, with just the customer name? Or are these lists readonly? (has to be)





    Mapping multi-tables to single list/entity-in-memory is easy, but when storing data back into the database is where the trouble begins.

  • Good point there. But, if it isn't Table Module, what is it? Active record?

  • Frans,





    If you add a row to the Orders, you'll have to specify a CustomerId. DeKlarit won't add the Customer (it makes no sense to add it).





    When you retrieve it, it will retrieve the CustomerName too, and in that case, you could update the CustomerName. As that's not probably what you usually want, you just can do it with a business rule. For example, suppose I have an Invoice entity and I want to subtract the quantity sold to the Product's stock, I can have a Deklarit Business Component defined the following way:





    InvoiceId (PK)


    (...)


    (nested level, 1 to many rel)


    ProductId (PK)


    ProductName


    ProductStock


    InvoiceLineQty





    and the following rule:





    subtract(InvoiceLineQty, ProductStock);





    This will update the product stock, which will be in the Product table.





  • Jesse,





    ... it's a good question. As not all of the OO design patterns are in GoF, perhaps not all the EoAA patterns are in Fowler's book ;).





    I'll try to lobby Martin to include this for the second edition ;).





Comments have been disabled for this content.