List of updated items :
1. I expanded the item "unit testing", added "3-in-1 document writing for Spec, Test script (Fit or Fit-like), and User Manual".
2. In the beginning I added references about architecture diagrams.
I thank vikas
http://vikasnetdev.blogspot.com/ , because both updates originate from responses to vikas's blogs.
==============================8 Basic Programming Techniques v4
Note: Those 8 techniques are described in a top-down style – I assume there is only one (basic) “architecture”, and you know THE architecture. I know it is unusual that we need to talk about THE “architecture” before we talk about the “basic” techniques. Actually, that is NOT that “unusual” -- without knowing those architecture diagrams, a programmer is working in the dark. Again, note that there are many diagrams, but they all convey the same basic architecture.
Reference diagrams from Sun (“Core J2EE patterns”) , Ejb community (“EJB Design Patterns”), and MS-MSDN best practice (“application architecture”):
http://java.sun.com/blueprints/corej2eepatterns/http://www.theserverside.com/tt/books/wiley/EJBDesignPatterns/index.tss)
http://msdn.microsoft.com/practices/topics/arch/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp----------------------backend techniques
----------------------The only thing I can argue about grouping logging with databases, is that for a long time, I always put them together. Perhaps it is because the most important logging is database access logging; perhaps it is because logging is somehow similar to database anyway. Note that the second logging in the middle-end is different from the first logging in the backend. The second one is focusing on the “aspect” aspect of it (the “client-side” of the logging); the first one is on the logging itself (i.e., the “server-side” of the logging).
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
----------------------middle-end techniques
3-4-5-6. Use the DynamicProxy in castle framework to centralize remoting(3), transaction handling(4), security(5), and logging(6), 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
----------------------front-end techniques
----------------------You may ask: why you put unit testing in the front-end group? Reason: I could put it in the middle-end. However, for a long time in my mind, it has always been in the front-end group, perhaps for two reasons: (a) it is an alternative of the UI code; (b) its very existence depends on the diligence of keeping UI code thin and clean -- remember, I do not believe in unit testing UI code -- that is the next generation stuff; not nowadays everyday practice.
7. The above security and logging can be at property level (i.e. "entity" level, instead of "facade" level or "data access logic" 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.
(there is more background info in this blog:
http://www.blogger.com/comment.g?blogID=26752431&postID=115078085354288833)
--- leverage the full power of the “custom class” in the age/context of “SOA”:
Javascript subset C# to Javascript translator. The good news is that I believe I found it in Ajax framework community.
8. Use Nunit, but only on façade methods.
8'. 3-in-1 document writing for Spec, Test script (Fit or Fit-like), and User Manual: Unit testing is the pivot in all development activities. However, that is easy to say than do. To get that done in a smooth and controlled manner, we need to take a larger perspective, hence this item. For details, please read my related blogs.
---- Note this does not mean this 3-in-1 document writing takes away the pivotal position of unit testing. Unit testing is still the king – from a developer’s biased/tunneled perspective anyway :-)
---- Also note that by this small step, we are combining XP (TDD) with RUP/UP/ISO 9000. Because the key idea of the latter is “document driven”; and “3-in-1 document writing” is “document driven”. I really believe that in the electronic world, when we routinely take notes in Word (OK, or “StarOffice”? – actually I take notes using VIM, so, do not flame me for being M$ centric) and emails, there is no justification to use those story cards or ORC cards or pieces of napkin anymore – although they sound romantic. In other words, we can expand this further: taking electronic notes is one of the eight basic programming techniques. I know it sounds craze; however, and take some observation yourself:
In meetings, how many people are taking notes using a paper notebook? I guess it will still take a while for us to use a notebook computer, a tabletPC, or, a smaller PDA, or, just use the “old” technique that use a piece of paper and then later put the notes into a computer. The latter practice requires discipline; but it works. Regardless, if you really think about it, contrary to what XP/TDD tells us, those paper notes are not and cannot be simply thrown away; as a result, those paper notebooks are at least one of the sources of unagility.
