http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Oren, I definitely agree with your example. However, just to be fair, if someone wanted to go ahead and implement a declarative caching strategy (or whatever strategy is in question), then one can probably encapsulate the different "policies" (i.e. expiration time policy, execution time policy, dependency query, etc) into distinct policy objects. You can, in turn, compose these policies (i.e. a chain of policies that can be evaluated to produce a boolean stating whether caching should be supported or not) and mark your field/property/method/whatever with an attribute that takes a type of policy that you want to use (i.e. [CachingPolicy(typeof(MyCachingPolicy)] ...). Additionally, one can create a policy composer that can read the app.config (or config from a custom provider) and create the chain of policies (Spring.NET could be used here, as could Windsor I suppose). Of course I'm just throwing out some ideas, but I certainly understand your main point that sometimes creating what could be perceived as an elegant design could, in fact, turn out to be not so "elegant." :) http://ayende.com/2277/limitations-of-declerative-coding#comment3http://ayende.com/2277/limitations-of-declerative-coding#comment3Tue, 03 Apr 2007 02:32:42 GMTI read the comment with interest, fully agreeing with you, until the last statement. Yes, there are very good reasons to breaking the rules, but breaking DRY and decoupling should really make you think before you try it. http://ayende.com/2277/limitations-of-declerative-coding#comment2http://ayende.com/2277/limitations-of-declerative-coding#comment2Mon, 02 Apr 2007 14:49:24 GMTSometimes I think we jump through rings of fire and eat little pieces of glass in an effort to find a pure, unleaky, elegantly decoupled abstraction. When the amount of effort that goes into this process becomes excessive and beings to produce a lot of complexity, sometimes IMO it makes more sense to not hide from the underlying database engine or other dependencies and just accept that it's not a perfect world. Maybe the piece of software you're describing is really nothing more than a thin layer of eye candy over a SQL statement anyway. Heretical, perhaps, and I wouldn't go this far most of the time; but my main point is, there are far, far worse things lurking in code bases than inline SQL statements. Conventional wisdom needs to be judiciously broken now and then. http://ayende.com/2277/limitations-of-declerative-coding#comment1http://ayende.com/2277/limitations-of-declerative-coding#comment1Mon, 02 Apr 2007 14:43:31 GMT