Review of ActiveObjects concept
Below is a review of Daniel Spielwak's ActiveObject for Java, as presented in an article on JavaLobby. Refer to the link to reference the original article.
Dynamic proxy vs byte code enhancement
ActiveObjects is interesting but could be improved by being implemented using byte code enhancement tools instead of Java dynamic proxies. Ruby, et al, are fine with taking the hit of dynamic binding overhead (people expect such overhead with scripting approach, as it's a conscious trade-off with respect to benefit of rapid development). Java is a compiled language, though, where performance is emphasized (and prized) for the purpose of building industrial strength solutions for enterprise class applications.
The author's phobia regarding byte code enhancement only serves to undercut his credibility. Byte code enhancement is well proven as many systems have been in wide use for several years now. In years of working with such tools, libraries, frameworks, languages (AspectJ), etc, byte code enhancement has never once been the cause of any issue or point of grief. Others have like experience or else the forums would be full of complaints.
Convention over Configuration
Convention over configuration is a utopian concept given that in practice enterprise development has to give sway to schema that is legacy and/or dictated by DBAs (and for good reason as relational database schemas need to be designed to perform well - not accommodate idealized object-oriented design).
In the end, for ActiveObjects to be realistically useful, there will need to be a way to use things like annotations in order to map the object perspective to the underlying database perspective. Or else the ActiveObjects entity interfaces could always be strictly generated by a tool that takes the database schema as its input (but event then there will be things that need to be customized via mapping overrides, etc.).
Creating Java interfaces for entities as the starting point only works out for sample apps, the simple Ruby-esque contacts CRUD app, or the occasional (but highly infrequent) green-field situation. Yet even there, a serious app of some complexity can get in trouble if database scheme is directly based on idealized object-oriented design. There are a lot of special things one does in the database to make operations perform well that would never have come from generating off of the object-oriented design of entities. Plus a pure, idealized object-oriented design could lead to pathological constructs in the database - from a relational database perspective.
When in Rome, do as the Romans. When living in the RDMS, do as the RDMS does things and life will be more pleasant.
Lazy-Loading
Lazy-loading seems like a fine idea from a naive (inexperienced) Java programmer's perspective, but in practice one has to work to minimize discrete trips to the database - or else will get thrashed on performance. Trying to always default to a simple heuristic, such as lazy-loading, is another concept that falls down in practice.
Business Logic in Entity Interfaces
Placing business logic methods into entities is pretty much a bad idea.
Often times it is desirable to convey entities over the wire (90% to 98% of the time) - that is, between the middle-tier and client-tier of 3-tier or n-tier distributed applications.
As such, entities need to be kept stripped down to pure data only, ala DTO (data transfer objects).
One of the very worst sins that one can commit is to pollute a distributed application with the anti-pattern of "distributed object interfaces". Attempting object-oriented programming that transparently spans across the network is discomfiting as the network is neither reliable nor deterministic.
Sticking with DTO approach to entities and then create services that operate on or with DTOs avoids such morass.
By tossing objects with behaviour and going strictly data-only, there are then some great enterprise messaging patterns that become possible. Those patterns will more than make up for the abandonment of OOP over the network.
The problem with OOP and network is that OOP as we understand it today is build on synchronous assumptions of behaviour interactions. Synchronous operations and the network mix like oil and water - bad combination. The second (or is it the first?) big problem with OOP over the network is tight coupling. Tight coupling is bad news for distributed application. Either one of these issues by itself is sufficient to doom this concept.
Summary
ActiveObjects needs to have the perspective of another five to seven years experience developing real-world enterprise applications.
The shear rapid ability to write working code, ala Ruby and RoR, focuses on a very narrow part of the overall problem spectrum. When you concentrate so much on this part of the equation and neglect/ignore the others, then the end result is something of limited applicability.
The serious-minded tools/solutions that exist out there have endeavoured to address the wider range of issues that professional developers (at least those in the enterprise arena) confront.
Dynamic proxy vs byte code enhancement
ActiveObjects is interesting but could be improved by being implemented using byte code enhancement tools instead of Java dynamic proxies. Ruby, et al, are fine with taking the hit of dynamic binding overhead (people expect such overhead with scripting approach, as it's a conscious trade-off with respect to benefit of rapid development). Java is a compiled language, though, where performance is emphasized (and prized) for the purpose of building industrial strength solutions for enterprise class applications.
The author's phobia regarding byte code enhancement only serves to undercut his credibility. Byte code enhancement is well proven as many systems have been in wide use for several years now. In years of working with such tools, libraries, frameworks, languages (AspectJ), etc, byte code enhancement has never once been the cause of any issue or point of grief. Others have like experience or else the forums would be full of complaints.
Convention over Configuration
Convention over configuration is a utopian concept given that in practice enterprise development has to give sway to schema that is legacy and/or dictated by DBAs (and for good reason as relational database schemas need to be designed to perform well - not accommodate idealized object-oriented design).
In the end, for ActiveObjects to be realistically useful, there will need to be a way to use things like annotations in order to map the object perspective to the underlying database perspective. Or else the ActiveObjects entity interfaces could always be strictly generated by a tool that takes the database schema as its input (but event then there will be things that need to be customized via mapping overrides, etc.).
Creating Java interfaces for entities as the starting point only works out for sample apps, the simple Ruby-esque contacts CRUD app, or the occasional (but highly infrequent) green-field situation. Yet even there, a serious app of some complexity can get in trouble if database scheme is directly based on idealized object-oriented design. There are a lot of special things one does in the database to make operations perform well that would never have come from generating off of the object-oriented design of entities. Plus a pure, idealized object-oriented design could lead to pathological constructs in the database - from a relational database perspective.
When in Rome, do as the Romans. When living in the RDMS, do as the RDMS does things and life will be more pleasant.
Lazy-Loading
Lazy-loading seems like a fine idea from a naive (inexperienced) Java programmer's perspective, but in practice one has to work to minimize discrete trips to the database - or else will get thrashed on performance. Trying to always default to a simple heuristic, such as lazy-loading, is another concept that falls down in practice.
Business Logic in Entity Interfaces
Placing business logic methods into entities is pretty much a bad idea.
Often times it is desirable to convey entities over the wire (90% to 98% of the time) - that is, between the middle-tier and client-tier of 3-tier or n-tier distributed applications.
As such, entities need to be kept stripped down to pure data only, ala DTO (data transfer objects).
One of the very worst sins that one can commit is to pollute a distributed application with the anti-pattern of "distributed object interfaces". Attempting object-oriented programming that transparently spans across the network is discomfiting as the network is neither reliable nor deterministic.
Sticking with DTO approach to entities and then create services that operate on or with DTOs avoids such morass.
By tossing objects with behaviour and going strictly data-only, there are then some great enterprise messaging patterns that become possible. Those patterns will more than make up for the abandonment of OOP over the network.
The problem with OOP and network is that OOP as we understand it today is build on synchronous assumptions of behaviour interactions. Synchronous operations and the network mix like oil and water - bad combination. The second (or is it the first?) big problem with OOP over the network is tight coupling. Tight coupling is bad news for distributed application. Either one of these issues by itself is sufficient to doom this concept.
Summary
ActiveObjects needs to have the perspective of another five to seven years experience developing real-world enterprise applications.
The shear rapid ability to write working code, ala Ruby and RoR, focuses on a very narrow part of the overall problem spectrum. When you concentrate so much on this part of the equation and neglect/ignore the others, then the end result is something of limited applicability.
The serious-minded tools/solutions that exist out there have endeavoured to address the wider range of issues that professional developers (at least those in the enterprise arena) confront.
posted by rogerv at
1:24 PM
|
3 comments
