A No-framework Approach

I know this is very controversial. So, I want to say the following:

Firstly and utmostly, I am only a messenger.

Secondly, I am also a theorizer: I try to elaborate the reasoning.

Thirdly, I have been practicing it in some projects. I am not saying I have been doing it very enthusiastically; but I do find it has its merits.

--------------------------
The rules of the approach are simple:

No third party tools, no third party frameworks. Further, no in-house “official” big frameworks, no in-house “official” big “utilities” (small utilities or code-reuse are encouraged, of course). Code generation is forbidden also. Note that those "no's" include tools like Nunit (i.e., no Nunit!). Also note that “frameworks” are especially forbidden, because by their very nature, frameworks are very powerful, therefore, very harmful.

Let’s be crystal clear: it does not matter whether it is binary, commercial, free, or open source. For example, no third party controls, even those ones that we can buy the source.

This does not mean we cannot use third party software, for example, we use Source Safe, and add-ins for visual studio, as long as they do not affect the code.

------------------------------

I believe this approach is from VB tradition; however, with unit testing, it can also be a variation of TDD (however, the irony is that Nunit if forbidden also!).

Why it is preferable? There are the following reasons:

(1) Fast to develop, no upfront learning curve
(2) Easy to upgrade, easy to maintain, by anybody, at anytime
(3) Developers learn a lot in such environment – I know, this is surprising, but it is true. This is also the core spirit of XP/TDD. Also, this does not mean we do not study frameworks. We do; we study, then, we tear them apart, or wrap them up, and only use the best one karat out of many tons stuff.


Why this approach is still applicable now? – Because .net 2.0 is more mature. For example, we have a much better grid, so, there is no pressing need for third party grids.


OK, let’s examine the "eight things for enterprise computing", to make sure:

(1) Logging: we need to wrap log4net anyway; so, we can use the thin wrapper of the log4net in the beginning. If later we really need it, we can “violate” the rules and introduce log4net later;

(2) Data access: the earlier version of the application block from M$ is just a few files. So, this is certainly easy to do;

(3) – (6) Use regularity and snippet (i.e. use copy/paste approach), instead of command/code generation/emit, for all façade level cross-cut concerns (logging, security, transaction, remoting);

(7) Unit testing: we can use the same idea of Nunit, but without using the software! We just use a few in-house methods (AssertEqual etc).

(8) Databinding/validation-formatting: no collections for custom classes, use dataset instead (however, if no need of collections, then, custom class can be used when needed). [update: no dataset! so, just simple direct ado reader; we can use reflection to simplify it a little].