[kforge-dev] KForge architecture

[Rufus Pollock]

John Bywater wrote:
[snip]
> 
> Now, at least two questions arise:
> 
> 1. Why not write KForge as a Django application?
> 
> The first answer is that KForge was started months before Django was 
> released. The second answer is even if it had been released before 
> KForge was started, it would still have been preferable to build a 
> Domain Model system for KForge, rather than sitting on a Data Mapper, as 
> Django does with SQLObject:

One would also note that in relation to django that:

   * like most webapp frameworks its controller model is very limited so 
its more like MV(c) than MVC
   * it elides the distinction between model and view not only by using 
its model as the datamapper but also using its model to specify 
extensive amounts of view metadata

This second point is particularly important. By putting all the view 
metadata cruft (and even metadata for its admin app) into the model you 
end up vastly reducing the seperation between model and view which 
completely defeats the purpose of using the pattern in the first place. 
As a consequence you end up with a 'fat' model with huge numbers of 
metadata paramemters for each attribute and very little ability to 
decouple views from the model.

> 2. Why build a Domain Model, rather than sitting on SQLObject?
> 
> The Domain Model pattern provides the composite pattern, allowing domain 
> object classes to be designed as a composite class hierarchy. For 
> example, basic named, dated, stateful, standard (=>named+dated+stateful) 
> Domain Object classes can be defined, then efficeintly concrete Domain 
> Object classes can be derived, and also extended by others.
> 
> Additionally, the KForge Domain Model semantics are those of object 
> oriented design (HasA, HasMany, String, Integer, etc.) which is useful 
> for modelling a domain. At the same time, because SQLObject is an 
> excellent implementation of a Data Mapper, it quite rightly has 
> semantics that correspond to relational database management systems 
> (ForeignKey, StringCol, IntCol). That is why KForge makes use of 
> SQLObject through the KForge Data Mapper, which effectively provides 
> programmatic control over SQLObject, and reflects the Domain Model into 
> the RDBMS.

This can be summarized as 'Anemic domain models are a bad idea', i.e. 
don't use your data mapper as your domain object. See Martin Fowler's 
discussion of this as an antipattern at:

  http://www.martinfowler.com/bliki/AnemicDomainModel.html

In fact, the persistence is so important that some people begin with the 
design of the persistent storage (e.g. DB tables) and end-up with a 
so-called Anemic Domain Model and a separate "Service Layer" consisting 
of queries to the persistent storage. Martin Fowler et al. have 
identified it as an anti-pattern. Such tight coupling of the application 
code and the persistence one, makes it very hard to unit-test your 
application - makes application code less reliable and extensible.

Regards,

Rufus