Discriminating Against Special Case Entities
This is something that I'm really struggling with as I pick up O/R knowledge. I'm going to attempt to describe my confusion using a trivial example so I hope this is clear...
I'm building a bank account management system. I need to track different types of accounts, transactions, etc. Typically, types are structured in the database as reference data (look-up tables, pick your poison). So, I'll have an Account table and an Account ENTITY. There could be several types of accounts, like Savings, Checking, Money Market, etc. and these values exist in the AccountTypes table. Same goes for transaction types.
Obviously, all this data needs to be maintained. New types of Accounts are created, retired (read deleted, for simplicity's sake, please...) and if there needs to be a corresponding ENTITY, ok no big deal. However, I'm going to have business logic that is going to depend on what type of account I'm working with; if it's a checking account that you earn an extra dollar every time you have a direct deposit, I'm going to have to accommodate that logic.
I feel this is where ENTITIES and O/R mapping are causing me heartburn. The OCD part of me says that everything needs to be identical, so I need an ENTITY for the account type data. Great. Pretty even. The design is consistent. However, when I go to check what type of Account I'm working with, what am I going to check against? My only option at this point is "theAccount.Type.Id = 1234".
"I smell man flesh."
OK, maybe not. But human-injected duplication is a repulsive as rotting flesh. Plus, this makes deployment a bear because, now, all the IDs have to stay the same or else you break your code. But, if I make the AccountType ENTITY a SPECIAL CASE so that "theAccount.Type = AccountType.DDBonusChecking", I'm forced to rebuild/redeploy the application any time a new AccountType is created. Not only that, but I feel that I've now sufficiently mucked-up my database design as well because there's no real "need" to have the AccountType table since they all exist in the code anyway.
It's possible that I'm making the situation much worse than it actually is. However, this is something that my group does in applications regularly; that is, we give the customer the ability to manage their reference data. When we weren't using ENTITIES and just DataSets and stored procedures with business logic, it wasn't an issue. Just look up the value and move on. There doesn't seem to be any direct analog to that with ENTITIES that is as elegant...
I'm building a bank account management system. I need to track different types of accounts, transactions, etc. Typically, types are structured in the database as reference data (look-up tables, pick your poison). So, I'll have an Account table and an Account ENTITY. There could be several types of accounts, like Savings, Checking, Money Market, etc. and these values exist in the AccountTypes table. Same goes for transaction types.
Obviously, all this data needs to be maintained. New types of Accounts are created, retired (read deleted, for simplicity's sake, please...) and if there needs to be a corresponding ENTITY, ok no big deal. However, I'm going to have business logic that is going to depend on what type of account I'm working with; if it's a checking account that you earn an extra dollar every time you have a direct deposit, I'm going to have to accommodate that logic.
I feel this is where ENTITIES and O/R mapping are causing me heartburn. The OCD part of me says that everything needs to be identical, so I need an ENTITY for the account type data. Great. Pretty even. The design is consistent. However, when I go to check what type of Account I'm working with, what am I going to check against? My only option at this point is "theAccount.Type.Id = 1234".
"I smell man flesh."
OK, maybe not. But human-injected duplication is a repulsive as rotting flesh. Plus, this makes deployment a bear because, now, all the IDs have to stay the same or else you break your code. But, if I make the AccountType ENTITY a SPECIAL CASE so that "theAccount.Type = AccountType.DDBonusChecking", I'm forced to rebuild/redeploy the application any time a new AccountType is created. Not only that, but I feel that I've now sufficiently mucked-up my database design as well because there's no real "need" to have the AccountType table since they all exist in the code anyway.
It's possible that I'm making the situation much worse than it actually is. However, this is something that my group does in applications regularly; that is, we give the customer the ability to manage their reference data. When we weren't using ENTITIES and just DataSets and stored procedures with business logic, it wasn't an issue. Just look up the value and move on. There doesn't seem to be any direct analog to that with ENTITIES that is as elegant...
posted by Harris at
10:54 PM
0 Comments:
Post a Comment
<< Home