Core OTTEC Techniques
After “8 OTTEC (123 Enterprise Computing) Issues” and “Core .net Tools and Frameworks”, here are the “Core OTTEC Techniques”.
Note that I keep the technique item numbers corresponding to the 8 issues; also, you can find the links to the tools and frameworks in the previous post, or, in the “Links” section of this blog site.
OTTEC Techniques:
1. Use log4net, in a simplistic style (avoid fancy stuff)
2. Use MS Ent Lib’s data access block
2’. Use Nhibernate, instead of Ent Lib, when we are in “advanced” situations
3-4-5-6. Use the AOP in springframework (or the DynamicProxy in castle framework) to centralize remoting, transaction handling, security, and logging, at the façade level.
Note: In order to do that, Use programmatic IoC (i.e., centralize all “Factories”); but for most projects, do not use XML style IoC (that is too heavy)
7. Use the custom class business rule validation technique in CSLA; but via AOP (see above about AOP, but at property level).
7’. Use the “custom class databinding” technique in CSLA; but via AOP (see above about AOP, but at property level).
---- Note that I said that we use techniques from Java; but CSLA originates from classic VB and VB.net. Further, the “custom class databinding” is indeed a new thing in .net. I admit that it is close to an over generalization; however, please also note that the idea of “custom class and business rule validation” is the mainstream in Java. There is no dataset "pollution" – at least in the days when the mainstream convention was established. The same logic applies to MS Ent lib’s data access block. Wrapping JDBC is a routine, mainstream practice in Java -- that is, if you have not graduated to using OR mapping (e.g., Hibernate).
---- I intentionally use the “over generalization”, is to emphasize that it is a painful learning experience for a classic VB team, to introduce those techniques. The fact that CSLA originates from classic VB, and MS Ent Lib has no direct Java origin, does not change the fact that those things are “routine”, common sense practices in Java, but in a VB team, typically you will have to have serious uphill efforts to introduce them, one by one, sometimes.
8. Use Nunit, but only on façade methods
In my next post, I will give an example, i.e., we will have code! Running code is the king; and the king is coming.
posted by survic at
6:50 PM
2 Comments:
Lot of Nice suggestions.
The following statement has prompted me to write this post which I have been thinking for some time.
“Use programmatic IoC (i.e., centralize all “Factories”); but for most projects, do not use XML style IoC (that is too heavy)”
I totally agree with him.
XML which was considered a panacea to ills of all world problem is now being denigrated as XML Hell or angle brackets. We, programmers abuse a technology and use it in a way not required and then blame the technology, not ourselves. The solution that we seek is getting a new technology in stead of using technology in pragmatic way.
My question to XML‘s critics is what is alternative. We need a text format with Meta information for cross-platform application Integration. Database is not the right answer in all situations.
One example of abuse is using O/R Mapping information in XML File . In .Net world, we could have simply avoided these XML files by using Custom Attributes. Lot of people copied the XML style IoC from Java world with out realizing that pre Java 1.5 there were no custom attributes or (annotations as called in Java World) . Post Java 1.5, even Java Evangelists are recommending use of custom attributes or annotations. XML style IoC may be good in situations where are writing code which requires third party APIs.
Just saw your comment. You are right; however, I also sensed a little anti-java thing (perhaps not intended though ;-). So, to be fair to java, I need to point out that for a long time, people who use Java Hibernate (OR mapping) use xdoclet, which is a similar thing of the attribute (but compile time). Note that xdoclet is an extension of javadoc, which is also already an "attribute" programming (but only complie time though).
Javadoc is build-in from the begining, and Xdoclet is there for a long time before 1.5.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home