three analysis questions and eight programming techniques

OK, enough for technology craziness. My pragmatic attitude and “tearing things apart” attitude is taking over now. As I said, I want this blog to be an honest trace record of the journey. The reality is always a result of many forces.

I am backing off from spring-everywhere stand – however, I still believe it could be done; it is just not that, well, pragmatic, that it is everywhere and all the time. Because it could be done, so, from now on, spring will always be my “reference” architecture. ------ a second thought: other than the last one (all virtual), and the wrapping "new" is to prepare the wrapper for Castle or Spring.net, the whole thing is perfect for absorbing CSLA also -- each item can benefit from CSLA, especially I would like to see how CSLA deal with silverlight's databinding (or not, I've just found a link -- I will put it in my next blog). Ya, both CSLA and spring have validation. I know, I am riding the fence now. As I said, I like CSLA a lot -- once it is simplified.

The key for backing off the extreme stand is that it is not about whether it could be done or not, it is about ("cooperative" and "friendly") competition for delivering client-visible business values. Another way to put it, I see those “values” as territories. You must cover the territories as fast as you can. If you do not, somebody else will. Once you put it this way, it is really very clear that it is to both our clients’ and ourselves’ best interests to deliver business values, instead of “architectures”. This is XP tradition also, by the way.

Let’s be back to the reality; let’s reiterate the forest view, the big picture:


A. Process -- always ask three questions:

(1) Application level use cases (or, stories)
(2) Screen level use cases (or, stories)
(3) Ubiquitous glossary, i.e., data schema with example data. Note example data are crucial


B. Technology -- always pragmatic AOP. The bottom line is the AOP rule -- “separation of concerns” (you may say it is also an OOP rule; however, OOP never directly and intuitively says it; also, OOP cannot really do it anyway!). There are several core concerns (not surprisingly, they correspond to my “eight core techniques”; however, I “collapsed” the façade items, and “expanded” entity times – it is understandable, I am now paying more attention to fine-grained AOP – even now, in this blog, I am withdrawing a little bit from an extreme stand I posted in my previous blogs – I know, back and forth, it is me – I want to explore all the extremes), and we must always separate them. Before I list them, you may say that since fine-grained (i.e., entity property level) AOP is so powerful, we can do everything dynamically; why bother those static “separations”. The answer: (i) so that we do not need to use fine-grained AOP everywhere and all the time where/when it is not absolutely necessary; (ii) for fewer bugs. Bugs are done by human minds; human minds can deal with linear and static things with fewer bugs.


(1) adowrapper (can be simple and ad hoc ones, so that we can log data access easily)
(2) log4net logging (wrap it or not; not important; log4net is a small dll)



(3) façade
--Dao: it includes dao, i.e., a dao can be called directly as a façade; as long as more complex logic are in façades, there is no need to separate dao from façade – some may say that it is needed for transaction handling; but the system should be smart enough to figure that out
--command desing pattern: we could use command as façade. However, I tend to use anonymous delegate within façade; as a result, explicit command is not necessary.



(4) entity (M) -------I use MVPC -- I use both P and C: P is for fake C from M$ ;-)
--dataset: note that this entity is the real one, not dataset; actually, dataset should be forever forbidden, except in some extremely isolated, rare, and well-justifiable contexts).
--validation: a simple, almost “ad hoc” validation mechanism (ad hoc “framework”) can be used here.

(5) view (V) Always use silverlight.
--fallback to ajax. Silverlight is good because all entity logic can be done without tranlating into javascript, while for ajax, it is already a headache just for validation logic (only part of entity logic). ------need activeX-javascript to make ajax model closer to desktop's power.
--fallback to WPF when it is really necessary. ClickOnce is not enough. The so-called “30 min. download” is not as easy as it sounds. It is a huge technology tumbling stone. Do whatever is necessary to avoid fat clients. Period.

(6) presenter-in-view’s-code-behind
--databinding is good: it can be thinner with databinding;
--but more difficult: because entity is not dataset, so, databinding must be “custom-class databinding”;
--silverlight needs "manual" databinding: silverlight does not support it; we need to do it by ourselves -- http://www.lhotka.net/weblog/WindowsFormsDataBindingIssueConclusion.aspx , or/and, spring’s web databinding) ----------I've just found a blog, very nice one (see my next blog) (P)

(7) view flow: user control -- always to use user control to wrap the whole page, and a page is used only for flow; at least it should have a standard method call so that it can be easily searchable. (C).



(8) Unit testing everywhere all the time – OK, this is a lie (I am pragmatic; what I really care is that it is doable that it is everywhere and all the time -- as long as we put all logic outside UI, this is done automatically; however, I do not care about actually doing unit testing all the time – give me a break: if it is not likely that it will break, why bother, let QA department deal with it – I am busy to deliver business values!). However, I added one important thing that I obtained from recent technology craziness (the irony is that I put this in my blog long time ago, but I did not really do it systematically):

--Always wrap all “new”: no need for a full fledged abstract factory, just put all those ceateXXX in a class, all createXXX are static. We do not need to switch the kit at runtime. Compile time switching (for testing), we just switch the class. As a result, we can do this in a very simple and ad hoc style. Who said AOP is difficult? Who needs those abstract classes or interfaces! ------For added flexibility (“configure the class” based on where is it!), we want to enter calling class also. We do not enter method name and variable name, we could, but it is too much trouble, and who needs that kind of flexibility anyway (you rewrite the code!) Note that we add class name very easily, we need to do it anyway for logging! -----note that using this approach, we do not need to add the called class in the data member of the calling class. Spring encourages us to do that, so, let’s do it; it does not hurt anything.

--Always use “virtual”: for all methods/properties, unless you really know you want it non-virtual (just like in java, virtual is the default, unless you really need to mark it “final”)