A simple question about design patterns

All --

Please help.

I have a simple question about design patterns.

I need a quick design-pattern spot-check and thought a guru might have a minute.

I am not certain which design-patterns (if any) I am using or if I am using them correctly.


The short story...

I have a 1-to-1 mapping of DatabaseRow-to-Entity, where each Entity class just holds data.
I have a 1-to-1 mapping of EntityManager-to-Entity, where each EntityManager class just handles CRUD operations for its Entity.
If handling multiple Entity objects, they are collected into typed collections that are data-bindable.
I have a single DataContext that is used only by the EntityManager classes, and the DataContext knows how to connect to the database and run SQL-based CRUD operations

I think this uses TableModule + TableDataGateway + RowDataGateway + DataMapper.

What do you think?


The long story...

Here is what I do.

For each database table, I have one simple "Entity" class that maps directly to the table row. The Entity exposes each database column as a public property. The only logic in the Entity is validation logic, (such as IncomingValueForProperty1CannotExceedNCharacters, IncomingValueForProperty2CannotBeNull, etc), which simply throws an exception if there is a validation error. There is nothing else in the Entity class-- no SQL, no connection information, no database information, no SaveMethod, no UpdateMethod, nothing, etc. In short, the Entity just holds data. A sample name would be "AddressEntity".

Multiple Entity objects are collected in various says, such as a typed-collection, an array of objects, an EntitySet, or similar.

For each Entity, I have an "EntityManager" class. The sample name would be "AddressEntityManager". The EntityManager has methods like Create(AddressEntity targetEntity) and Retreive(object ID) and Update(AddressEntity targetEntity) and Delete(object ID). The Manager knows how to get data from the database based on an ID and return the data as a Entity. The Manager knows how to take an Entity passed to it and save the Entity to the database. Etc. The EntityManager uses the DataContext.

There is a single "DataContext" class that is used by all EntityManager classes. The DataContext class that knows how to connect to the database and conduct low-level CRUD, SQL-based operations.

This is very easy to implement and use. In particular, it is very clear to see who does what in terms of responsibility. The Entity holds data. EntityManager performs CRUD operations on an Entity. Need an Entity? Ask an EntityManager. Need to do something to an Entity? Ask an EntityManager. It is transportable, in that it can be used on virtually any typical database-driven application. IMHO and IME.

A typical implementation is ASP.NET plus C# plus Linq-To-Sql (or Linq-To-Entities) plus SQL Server.

What pattern (or patterns) are expressed here?

I do have some ideas about which patterns are used. This way of working seems to have aspects of several patterns.

For "Domain Logic Patterns", it seems to have aspects of...
Table Module
(Reference: Martin Fowler)

For "Data Source Architectural Patterns", it seems to have aspects of...
Table Data Gateway
(Reference: Martin Fowler)
Row Data Gateway
(Reference: Martin Fowler)
Data Mapper
(Reference: Martin Fowler)

However, I want to get your views on the matter, especially to help correct the design and improve it.

What do you think?

Please advise.

Thank you.

-- Mark Kamoski