8 Core OTTEC Techniques v2

This blog (I added "8" in the title to make it easier to remember the key points) is effectively my “default” architecture: it does not mean that I will blindly use it everywhere; it means it is the starting point of my thinking -- software is soft; it is about the tradeoffs. However, we do need a starting point; we cannot think everything from basic OO or language syntactical features.

As a result, this blog is likely to be re-posted regularly, to reflect the changes of my architecture thinking.

----------------------------------
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 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)

--- to avoid client casting, use factoryMethod
--- use abstrctFactory for switching easily
--- put class name, method name, variable name in the factoryMethod



7. The above security and logging can be at property level;
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).
--- class-to-form using custom event
--- form-to-class (onchange; no exception in set; use rule)

--- tip: listview/read-only-grid read-only: this is good for user anyway;
so, no need of typed collection (note: sorting etc are control's business)
--- tip: update's return object: only get the seq and update the property
do not try to replace the whole object
--- tip: use read-only properties to "borrow" fields for m-m-like
--- tip: inheritance or parent -- pass reader, tx, parent etc.


--- "CSLA with dynamic proxy/aop":
(a) not limiting to 4 (CRUD) methods;
(b) so, no need of special workflow objects,
(c) so, no need for special “criteria” and “exists” classes.

(d) At property level, cleaner property/get/set,
because no CanRead/WriteProperty, PropertyHasChanged calls.



---- 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