Too many technologies, framework or not and aop, and spring.net

Too many technologies, framework or not and aop, and spring.net

A. It is a common feeling that M$ offers too many technologies. This is especially troublesome for team leadership -- some "new" developers keep introducing stuff, all M$ "recommended".

To deal with it, we have to say: you cannot use new technologies, just because you can and they are new. They must be relevant and make sense.

I go further. Using new technologies must fit into two categories: it directly meet users' needs of certain features, or, it solves the issues that the "8 core techniques" try to solve.

(1) The core of the core? coarse-grained AOP, of course: centralized security, logging, transaction, and networking.

(2) Below it, the logging (implementation) and database acess.

(3) Above it, fine-grained AOP (entity logic-validation), and MVC (or, MVPC) -- i.e., databinding.

If a new technology does not help solving those problems (and not directly address a feature needed by users), then, forget about it.

B. Framework or not

(1) The key is how effective a coding guideline or an architecture guideline can be. My bet is that they rarely work! You cannot solve an engineering issue by using pure managerial techniques. You must "automate" the "guidelines", which is a framework!

-- The only real effective guidelines are those that enforced by a framework.

(2) Another key is how fast you can get implement features in security, logging, transaction, networking (and validation), with reasonable (acceptable) quality. My experience is that you rarely can, without a framework.

-- The only fast and easy way to implement reliable security, logging, transaction, networking (and validation) is to use a good (and easy) framework. -- note that here, a framework helps you get things done faster, not slower!

Note that I backed off from spring.net, because I cannot convince people about this, and I have to accept the consensus at that time. However, it turns out that it all depends on the size of your vision and perspective. If it is large enough (e.g. anything > 7 person-year, no mention a whole enterprise system), then, it should be spring.net.

Also note that I am more and more convinced that AOP is the center here, not IOC or TDD. The key is that AOP is inherently feature-oriented -- you need those security features!

C. choice among Spring.net, castle, M$ entlib 3.0:

(1) needs politically correctness for a M$-only shop: M$ entlib 3.0
(2) likes dynamic new challenges: castle
(3) is pragmatic, mature: spring.net (plus log4net, no need to use M$'s logging)