"Table Module" pattern

[Ketchupy]

I'm trying to get my head around the "Table Module" pattern (http://
martinfowler.com/eaaCatalog/tableModule.html).

In his book, Fowler suggest passing DataSets to the module instead of
creating them inside the module. He justifies that with "that creates
the data set away from the Table Modules, following the guidelines of
ADO.NET." What exactly does he mean by that? And what could be the
disadvantages if my Table Modules were responsible for getting
DataSets themselves?

 

[Mr. Arnold]

I'm trying to get my head around the "Table Module" pattern (http://
martinfowler.com/eaaCatalog/tableModule.html).

In his book, Fowler suggest passing DataSets to the module instead of
creating them inside the module. He justifies that with "that creates
the data set away from the Table Modules, following the guidelines of
ADO.NET." What exactly does he mean by that? And what could be the
disadvantages if my Table Modules were responsible for getting
DataSets themselves?

From what I have gathered by reading Flower's take on this, it means that
the dataset should be instantiated in the BLL or DAL for a Datatable, as you
can add a Datatable to a Dataset at any point.

http://msdn.microsoft.com/en-us/library/aeskbwf7(VS.80).aspx

A class should act upon the Datatable to do business logic at the BLL, and
a class would be needed to do CURD operations at the DAL, with the DAL class
persisting that Datatable back to the database.

Employee.cs/vb that only works with the Employee table in the layers. A
EmployessHistroy.cs/vb that only works EmployessHistroy table, etc etc.

I do the same thing with an DDD, TDD and ORM solution one class that does
the business logic for the Employee entity at the BLL and one class in DAL
to do the CRUD for the Employee entity persisting it back to the Model.

The advantage of using a Table Module pattern from what I can see is that it
lends itself well to doing a Test Driven Design of the BLL and DAL.

 

[Ketchupy]

Mr. Rae, Table Modules can, according to Fowler, also work on views,
so it's not only one TM per table. Obviously, you can't get as much
flexibility with TMs as you get with Domain Model. But it seems like a
valid option, especially in the .NET environment which already gives
you DataSets for the TMs to operate on.

Patrice, basically it all boils down to data encapsulation problem for
me. Why should I bother creating DataSets and passing them to TDs if
they can create DataSets themselves and keep them hidden. Later I
could perhaps access them through TM's public properties and bind them
to the appropriate GUI control.

Mr. Arnold, actually Fowler in his examples instantiates DataSets in
the presentation layer. He is using "Table Data Gateway" (http://
martinfowler.com/eaaCatalog/tableDataGateway.html) to populate them. I
believe you're doing Domain Model in your case. This means that every
Employee object represents a single employee from the Employee table.
But in case of the Table Module pattern, Employee object deals with
the whole (disconnected) Employee table.

Thank you all for your feedback!