[kforge-dev] KForge architecture
rufus.pollock at okfn.org
Wed Apr 26 11:04:00 UTC 2006
John Bywater wrote:
> 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:
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.
More information about the kforge-dev