.NETified

This talk was given by Dino Esposito. Dino is a great speaker, and fun to watch. He’s very animated, and excited about what he’s talking about.

There are 3 principle architectural patterns for domain logic; Transaction Script (TS), Domain Model (DM), and Table Module (TM).

Transaction script has components mapped to required functionality. It’s simple but has the risk of duplicating code. This pattern is not ideal for .NET.

Domain model has each object map to a record. This is most flexible and the only pure object oriented option. This has no dependency on ADO.NET facilities.

Table module manages a table of data. A benefits is you have record set like data structures.

Ideally, opt for an architectural design pattern. Find the proper design pattern for the data source.

Data  source patterns:

• Row Data Gateway – Table Module
• Table Data Gateway – Table Module
• Active Record – Domain Model
• Data Mapper – Domain Model

Row data gateway has an object that acts as a gateway to a single record of data in a table of view. There is one instance per row. There is a direct correspondence between properties and columns. A row data gateway should contain only database access logic but no domain logic.

Table data gateway has an object that acts as a gateway to a table of data. It holds all the code to access a single table or view and perform CRUD methods.

What should a find by id method return?

• Appropriate domain object if used with domain model.
• A data set if used with table module.
• A DTO filled with data only if used with transaction script.

This works well with table module.

Active record has an object that wraps a table or view row. It encapsulates database access. it exposes the same behavior through methods. It’s a domain model in which classes match closely the record of an underlying database table or view. There is no abstraction. The types are the same as the SQL types; no conversions. It leaves foreign keys as they are.

Typical methods for active records:

• Create an instance of the object from SQL data.
• Create an instance in memory for later insertion.
• Has static finder methods for common queries.

A data mapper has mappers that move data between objects and a database table. It transfers data between in memory objects and related database tables.

Typed datasets:

• What’s good?
• Built in optimistic concurrency.
• Handle complex relationships between tables.
• Has serialization and persistence.
• What’s bad?
• Weakly typed and generic container.
• No way to new up the individual data item.
• Hard to deal with scalar values.

Collections and custom objects:

• What’s good?
• Strong typing and more compact objects.
• Can represent data aggregated from multiple sources and free form.
• Enables you to add behavior to objects, not table of objects.
• What’s bad?
• Manual coding of most features.

LINQ-to-SQL

• There’s a clear trend to move business logic towards objects.
• Real objects, not just data containers.
• Data and behavior.
• Domain model.
• Simple schema through active record.
• More complex schemas through data mapper.
• LINQ’s query language on top of objects.
• LINQ-to-SQL is a kind of active record.
• LINQ-to-Entities is a kind of data mapper.
• Use LINQ-to-SQL partial classes to create business domain layer and extend its functionality.
• LINQ-to-Entities is the best way.