Reflection on Repository
I looked into Jeffrey Palermo's architecture and, just about like anyone else new to TDD, I questioned "all the code". Unlike everyone else, however, I did not question the code for the tests; I had problems with all the code for mere data access.
Palermo's architecture makes use of Fowler's Repository pattern and that's mainly when flags were raised for me. Fowler states in describing the pattern that "a simple extension of the Repository pattern allows different querying strategies to be employed depending on the situation." [Fowler, Patterns of Enterprise Application Architecture, 2004]. Part of me wonders if he should've just flat said "if you implement this pattern abstractly (interface or base class), it allows for a more testable design" and left it at that.
But, unfortunately, my mind doesn't just accept that possibility alone and continues to wonder: what's the value of this outside the unit testing fixtures? I'm hard-pressed to imagine a situation where an application would need multiple data access strategies for the same domain objects.
On top of all that, Fowler mentions that the Repository pattern removes the query mechanics from the client and allows the code to be less dependent upon itself. I'd really like to see an actual implementation of this pattern using NHibernate since it incorporates the Query Object that Fowler describes and I feel it would put the pattern in better perspective.
I am not trying to take the position that this is not a useful pattern and/or that it should be abandoned. I completely agree that applying the Strategy pattern with the Repository allows for extremely testable code. However, any time I've entertained implementing the Strategy pattern it almost always seems as though it comes up as more of a "plug-in" or "provider" implementation. By this I mean that I feel the need to dynamically determine, based on domain data, configuration settings, etc., and Palermo's architecture doesn't fit that description. The tests use statically mocked/stubbed objects to ease the work the testing framework has to do in order to still perform valid execution of the code under test.
Finally...what about the security implications of exposing all the "core" architecture as interfaces or other abstract OO methods? For example, in Palermo's architecture, the ConfigurationService object provides a read/write property for the IDataProvider. I understand needing the write accessor so that the Repository can be mocked, but, to me, it seems as though the code is "more vulnerable" because malicious code could possibly dynamically reflect on the application and inject a malicious implementation of the IDataProvider. This is not to say that I feel that dynamically creating types from the applications configuration file is completely secure and is the only way to go. It just seems to me that it exposes the code more and violates the "minimize the attack surface of the code".
(disclaimer: I do not claim myself to be a security guru nor do I "real" developer with any "real" knowledge of anything "real"...so, don't take it all with a grain of salt...)
Am I completely off base with all this?
Palermo's architecture makes use of Fowler's Repository pattern and that's mainly when flags were raised for me. Fowler states in describing the pattern that "a simple extension of the Repository pattern allows different querying strategies to be employed depending on the situation." [Fowler, Patterns of Enterprise Application Architecture, 2004]. Part of me wonders if he should've just flat said "if you implement this pattern abstractly (interface or base class), it allows for a more testable design" and left it at that.
But, unfortunately, my mind doesn't just accept that possibility alone and continues to wonder: what's the value of this outside the unit testing fixtures? I'm hard-pressed to imagine a situation where an application would need multiple data access strategies for the same domain objects.
On top of all that, Fowler mentions that the Repository pattern removes the query mechanics from the client and allows the code to be less dependent upon itself. I'd really like to see an actual implementation of this pattern using NHibernate since it incorporates the Query Object that Fowler describes and I feel it would put the pattern in better perspective.
I am not trying to take the position that this is not a useful pattern and/or that it should be abandoned. I completely agree that applying the Strategy pattern with the Repository allows for extremely testable code. However, any time I've entertained implementing the Strategy pattern it almost always seems as though it comes up as more of a "plug-in" or "provider" implementation. By this I mean that I feel the need to dynamically determine, based on domain data, configuration settings, etc., and Palermo's architecture doesn't fit that description. The tests use statically mocked/stubbed objects to ease the work the testing framework has to do in order to still perform valid execution of the code under test.
Finally...what about the security implications of exposing all the "core" architecture as interfaces or other abstract OO methods? For example, in Palermo's architecture, the ConfigurationService object provides a read/write property for the IDataProvider. I understand needing the write accessor so that the Repository can be mocked, but, to me, it seems as though the code is "more vulnerable" because malicious code could possibly dynamically reflect on the application and inject a malicious implementation of the IDataProvider. This is not to say that I feel that dynamically creating types from the applications configuration file is completely secure and is the only way to go. It just seems to me that it exposes the code more and violates the "minimize the attack surface of the code".
(disclaimer: I do not claim myself to be a security guru nor do I "real" developer with any "real" knowledge of anything "real"...so, don't take it all with a grain of salt...)
Am I completely off base with all this?
posted by Harris at
8:38 AM
0 Comments:
Post a Comment
<< Home