I've read a lot of books on software design, and more and more I'm wondering if what I learned about separation of concern between business object and serialization makes me more productive.
I'm influenced by Domain Driven Design, so when I design my business classes I don't think about persistance. The only objects who are coupled to my database/web service technology/caching technology are encapsuled behind a repository with a nice domain interface.
To illustrate, for a traditionnal application database<->web service<->RIA, I design my business classes Account and Employee.
Then if I want to get accounts from a data source I create a IAccountRepository, and implement methods to query, or add accounts to my data source.
To add caching capability to my application, it's only a matter of creating a proxy class which implements IAccountRepository and wraps the real repository, then inject it in my IOC container.
To implement a database repository, I use an ORM which create classes from my database schema, then I use create a translator to transform database classes to/from business classes, this way my business classes are decoupled from my database schema.
I also create dedicated data contract classes for my web services, then the web service use translators to transform an aggregation of business objects to its data representation from the web service perspective.
When I create my RIA application, again I design its own domain model, but this time the repository implementation use a webservice instead of the database (and again translators).
For WPF developers, I create then my ViewModel and my View.
I used to program like this.
BUT, when my boss comes and says : can you add a field to this form to… blah blah blah I must :
- Update my database
- Update my database translator
- Update my business object
- Update my web service translator (server)
- Update my web service translator (client)
- Update my business object (client)
- Update my view
- For WPF adepts, update my ViewModel
I'm more and more thinking to couple my business object with database access technology and web service technology or serialization technology.
This way I don't need to maintain my translators anymore.
For example why not using attributes/annotations of these technologies on the business objects ? Yes it brings some contrains, yes I will need a get/set on my fields, even if I want my property to be readonly, yes my business module will have external dependencies.
But I think it will result to less code, and a more maintenable system.
The implementation of my repositories will be trivial, and won't rely on translators.
Although I see advantages to code this way, I always feel guilty to code like this. I feel really guilty about adding a 5 attributes/annotations coupled with my data access technology/web service technology/Serialization technology on my business objects and I feel it's not right.
why my separation of concerns Database/Business objects/Web service, makes me write more code ?
Do you have some alternatives ?
Best Answer
Your personal productivity is not the point.
The point of separation of concerns is to increase the value of the software you produce by making it usable, maintainable and adaptable.
I'm sorry if this makes you write more code, but your time is typically a tiny fraction of the life-time cost of using, maintaining and adapting what you're writing.
Separation of concerns is essentially for keeping the life-long total cost of ownership down. It has little to do with your personal productivity.
If your boss is asking you for a pervasive change... well... it's pervasive. I'm sorry it's pervasive.
Edit 1
The value of your software is the value that is produced by people using it.
"Is it the purity/beauty of the code? To me, value is in simplicity and readability." It's neither. It's the value created applying the code to real-world problems.
If the code is hard to maintain, adapt or use, that devalues it. If the code is easy to maintain, adapt or use, then there are fewer barriers to getting full value from the code.
Your time developing the code is a tiny, tiny cost compared to the value of using it. Also, your time developing is a smaller cost than maintaining or adapting.
Edit 2
Pervasive change is an unavoidable consequence of building software. Nothing -- no practice -- can prevent your boss from making a change that breaks your architecture.
If you have one layer, almost any change breaks that layer.
if you have 3 tiers, 7 layers or n+1 layers, it's always possible for your boss to ask for a change that breaks more than one layer.
The idea is that MOST changes are isolated. Nothing can assure that ALL changes are isolated.