- Transaction Script. This pattern involves creating methods in one or a few Business Components (classes) that map directly to the functionality that the application requires. The body of each method then executes the logic, often starting a transaction at the beginning and committing it at the end (hence the name). This technique is often the most intuitive but is not as flexible as other techniques and does not lead to code reuse. This pattern tends to view the application as a series of transactions.
- Table Module. This pattern involves creating a Business Component for each major entity used in the system or service and creating methods to perform logic on one or more records of data. This pattern takes advantage of the ADO.NET DataSet and is a good mid-way point between the other two. This pattern tends to view the application as sets of tabular data.
- Domain Model. Like the Table Module, this pattern involves creating objects to represent each of the entities in a system, however, here each object represents one Business Entity rather than only having one object for all entities. Here also, the logic for any particular operation is split across the objects rather than being contained in a single method. This is a more fully object-oriented approach and relies on creating custom classes. This pattern tends to view the application as a set of interrelated objects.
In additon to these patterns I'll also look at how the Service Layer pattern interacts with these. Should be fun.
No comments:
Post a Comment