Frans Bouma on How-To-Select an O/R Mapping Tool for .NET (2006)

You need to make a connection between business logic and persistent storage. How you do that depends on how you see your data. To test your way of thinking, imagine that a customer gets the gold status when he spends at least $25,000 in one month. Where is that logic placed? Does it get read in a Customer object to test the rule or is it in a CustomerManager that executes rules and consumes customer objects or DataSets? These are different views of data, which result in different ways of solving the DataAccess problem.

The table approach uses no theory, just a set of tables not based on any abstract model, and they're created right there in DDL. You use tables and expect to work with them in memory as well, so a plain DataSet/DataTable approach with stored procedures or Visual Studio .NET-generated SQL statements is appealing. If this is your way of working, you won't need an object-relational mapper.

The entity (Chen/Yourdon) approach is different. The relational model is built with an abstract model. This means you speak of entities (or relations) and attributes. An approach with DataTables/DataSets is not appealing, as the relational model speaks of customer entity and not of customer record. In this approach, you'll also want to use these types of elements in your code. Because you use a relational model as your base of thinking, the entities, by definition, don't contain behavior/rules. If this is your way of working, you can use a combination of object-relational mapping for the entity data and generic data functionality like Datasets/DataTables for the dynamic data retrieval requests.

The domain model (Fowler/Evans) approach focuses on domains, like the Customer domain or the Order domain. It starts with classes, like a Customer class, that contain the data for a customer and all behavior for the customer; all business rules for the customer are stored there. Through inheritance, you can create a compact model of classes and store the behavior you have to define in the class responsible for the functionality/data. You can use polymorphism to override/modify behavior through the hierarchy which is then stored in a database. If your way of writing software is like this, you'll need an object-relational mapper to work with the data in persistent storage. Because the system focus on data is through objects, working with data in lists like the table or entity approach is not available.