(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Thursday, September 13, 2007
Code/data separation and Encapsulation are diametrically opposed ideas
Think about this, hard, the next time you are considering the virtues of putting everything in a Relational Database. Code/data separation means that the applications of the future can operate on the data of today. Fine.
But then you decide that all applications should access the database through stored procedures, encapsulating the data schema. You just reversed yourself, you might as well have built middleware in a real programming language and exposed the data through web servcies or REST.
Either approach is fine. But just recognize that separating code and data works towards the goal of reusability in a manner that is diametrically opposed to building an encapsulation layer.
In fact, if you insist on code/data separation and you’re an advocate of OOP, then you’re talking out of both sides of your mouth. If your gut reaction to having log entries know how to transform or process themselves is “woah, that’s just wrong”, think again: you’re imposing a world-view on the problem that’s not consistent with your notions of data encapsulation and active objects.
Think about this, hard, the next time you are considering the virtues of putting everything in a Relational Database. Code/data separation means that the applications of the future can operate on the data of today. Fine.
But then you decide that all applications should access the database through stored procedures, encapsulating the data schema. You just reversed yourself, you might as well have built middleware in a real programming language and exposed the data through web servcies or REST.
Either approach is fine. But just recognize that separating code and data works towards the goal of reusability in a manner that is diametrically opposed to building an encapsulation layer.
Comments on “Code/data separation and Encapsulation are diametrically opposed ideas”:
<< Home
I'm trying to wrap my head around this all. It sounds like Steve's saying something subtly different here, but it may just sound different because of how I think of code/data separation.
Actually, I don't think much of it - when I build objects, I let them handle their own retrieval and database persistence through stored procedure calls. The logic's in the object and the stored procedure has (often redundant) logic enforcing data consistency.
What matters to me is that for anyone using the object, where the data comes from and where it goes is a complete black box. It knows how to do what it needs to do and it'll tell me if I did something wrong and I'll fix it.
Are you complaining about the duct tape feel of this? You've got a schema which is an object, the data which is an instance of an object, a stored procedure which is a DSL to retrieve an instance of that object so that you can instantiate another object in another language? Put like that, wow I'm astonished that 90% of the internet works but on the other hand, I don't know how I'd re-architect it and make it better.
I go with the database because I figure that people who get paid to write databases do a better job of safely and quickly storing and retrieving data than I could knock up by inserting more web services talking to a (somehow) organized file system store.
I'm going to be spending too many cycles wondering how this ungainly setup came to be elevated to "best practice" in the first place now.
Actually, I don't think much of it - when I build objects, I let them handle their own retrieval and database persistence through stored procedure calls. The logic's in the object and the stored procedure has (often redundant) logic enforcing data consistency.
What matters to me is that for anyone using the object, where the data comes from and where it goes is a complete black box. It knows how to do what it needs to do and it'll tell me if I did something wrong and I'll fix it.
Are you complaining about the duct tape feel of this? You've got a schema which is an object, the data which is an instance of an object, a stored procedure which is a DSL to retrieve an instance of that object so that you can instantiate another object in another language? Put like that, wow I'm astonished that 90% of the internet works but on the other hand, I don't know how I'd re-architect it and make it better.
I go with the database because I figure that people who get paid to write databases do a better job of safely and quickly storing and retrieving data than I could knock up by inserting more web services talking to a (somehow) organized file system store.
I'm going to be spending too many cycles wondering how this ungainly setup came to be elevated to "best practice" in the first place now.
When you separate the code and the data, how much of the knowledge of the data ends up intrinsically embedded in the code? You can't consistently parse Word documents exactly without having access to a copy of Word. Just separating the two is not necessarily reusable.
Huh?
When understood as objects, how is accessing a Relational Database any different than performing data queries/updates via a web service or REST?
Object -> tells object -> to do something.
Maybe I just don't get your point here.
When understood as objects, how is accessing a Relational Database any different than performing data queries/updates via a web service or REST?
Object -> tells object -> to do something.
Maybe I just don't get your point here.
Neil:
Everyone I talk to has a different idea what "Understood as Objects" means, so why don't I try to explain what I mean again and you can translate that into your understanding of objects.
Code/data separation is the belief that data lasts much longer than applications. You don't want your data locked inside of some proprietary format, hidden an API that was designed for what the company thought would be appropriate at the time.
This drives the use of a relational database, where SQL (or something like it) provides all the queries and updates you need today, plus the flexibility to add new ones tomorrow. Or to use new tools. Or to write reports.
Encapsulation is the opposite idea. It is the belief that you should only expose well-defined APIs, be they objects with a persistence layer, middleware, or stored procedures in the database.
If you have objects telling objects to do something, you likely have Encapsulation.
REST is a protocol, just like SOAP. You can think of it as working with rows in a database, or of working with abstract objects.
However, if you build a simple REST service that acts a lot like data (i.e. guarantee that if you PUT something, you can later GET the same thing, and so on), you can then build a client application in front of your REST service (possibly in a browser, possibly in a separate server).
You now have code (in the client application) and data (in the REST service).
It all depends on how you use it.
Everyone I talk to has a different idea what "Understood as Objects" means, so why don't I try to explain what I mean again and you can translate that into your understanding of objects.
Code/data separation is the belief that data lasts much longer than applications. You don't want your data locked inside of some proprietary format, hidden an API that was designed for what the company thought would be appropriate at the time.
This drives the use of a relational database, where SQL (or something like it) provides all the queries and updates you need today, plus the flexibility to add new ones tomorrow. Or to use new tools. Or to write reports.
Encapsulation is the opposite idea. It is the belief that you should only expose well-defined APIs, be they objects with a persistence layer, middleware, or stored procedures in the database.
If you have objects telling objects to do something, you likely have Encapsulation.
REST is a protocol, just like SOAP. You can think of it as working with rows in a database, or of working with abstract objects.
However, if you build a simple REST service that acts a lot like data (i.e. guarantee that if you PUT something, you can later GET the same thing, and so on), you can then build a client application in front of your REST service (possibly in a browser, possibly in a separate server).
You now have code (in the client application) and data (in the REST service).
It all depends on how you use it.
<< Home
