+972 52-548-6969
OR/M Is Not About Data
The main benefit of an OR/M is not that it can fetch data from the database. There are multitude of other ways to do this task.
The main benefit is that it makes us think about our model as a set of objects, and not as rows in tables. Objects has behaviors, inheritance structure, encapsulation, etc.
The ability to use OO tools and practices in all the layers of your application is fantastic. It means that I can replace case statements with strategies, that I get a general algorithms instead of thinking about the specifics.
Take the following tables, which contain the data about business rules that apply to some merchant.
Merchant: { Id, MerchantType, … }
Rules : { Id, RuleType, … }
Here is how I would have to handle if I was working on the data directly:
List<Error> errors = new List<Error>();
foreach (MerchantRow merchantRow in merhcants)
{
foreach (RulesRow ruleRow in rules)
{
switch (ruleRow.RuleType)
{
case 1:// no outstanding debts
switch (merchant.MerchantType)
{
case 3:// internal , no validation neccecary
break;
default:
if (business_logic)
errors.Add(new Error());
break;
}
}
}
}
I may be slightly exaggerating, but there is no way to avoid this in a table driven architecture. On the other hand, here is how I would handle this in an object driven architecture:
List<Error> errors = new List<Error>();
foreach (Merchant merchant in merchants)
{
foreach (Rule rule in rules)
{
Error error = rule.GetErrors(merchant);
if (error != null)
errors.Add(error);
}
}
All that ugly stuff about the rule type and merchant type are abstract away to objects with different behaviors. I got different types of rules, and different types of merchants, and I can work cleanly and effectively.
Adding a new merchant type is as easy as creating a new object , override several methods and mapping it to the database. I wouldn't care to find all the places where switch / case statements were used in a data driven.
This is just a tiny taste of what is possible. Given enough time and some clear thought, it is not hard to come up with some very crazy ideas that are so damned hard without taking objects all the way to the database.
Comments
Comment preview