Design Docu - Archtitecture

[John Ralls]

On Sep 27, 2014, at 1:14 PM, Carsten Rinke <carsten.rinke at gmx.de> wrote:

> Hi,
> 
> I made a first step in updating the documentation of the GnuCash Archtitecture:
> http://wiki.gnucash.org/wiki/Project_and_Design_Documentation#Introduction
> 
> My idea is to go through the "old" chapter of Architectural Goals and transfer parts of it into this "new" chapter where these goals shall be described as facts. Goals that are no facts remain in the "old" chapter (unless these are no valid goals anymore).
> 
> Every now and then (and probably in small steps) I will come back here to the mailing list to double check my understanding and to get hints whether I am thinking totally off track.
> 
> If what you see in the link above is somewhat hitting the truth, I would continue drilling down into the Model (and then come back again).
> 
> Is it somewhat hitting the truth?

Carsten,

It appears you’ve confused view part of the Model-View-Controller pattern [1] with database views [2]. More than one MVC view can represent a single database view: Consider a transaction that you are looking at in two registers. It’s the same data, but the presentation is different because each account has a different viewpoint about the transaction.

Also, controllers are the code that interacts with the model to change data. It need not be GUI: E.g., importers are controllers.

If you look at the diagram in [1], you can replace “User” with GUI, since it both presents views to the user and receives the user’s commands to pass back to the controller. This is actually a good implementation as well because with suitable shim classes it makes it much easier to use more than one GUI, something that’s necessary for accommodating both normal computers and “mobiles” like phones and tablets. 

As Christian points out, “the engine” is a bit fuzzy in the current code, but it certainly isn’t a layer between the model and the view or controller. Probably best to leave that out of this level of the discussion. I think I’d mention MVC with the wikipedia link and say that that’s where we want to go, but that the current implementation is a mess with pieces of each component intermingled and spread throughout the code-base.

Neither we nor any of the database backends we contemplate using support 2 phase commit [3]. Databases generally implement atomic commit [4], but we’re not using that feature in the SQL backend yet, and the XML backend is an all-or-nothing save driven by a timer or the user. The persistent classes currently implement a half-hearted effort at atomic commit but in general will fail catastrophically if anything goes wrong.

Regards,
John Ralls

[1] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[2] http://en.wikipedia.org/wiki/View_%28SQL%29
[3] http://en.wikipedia.org/wiki/Two-phase_commit_protocol
[4] http://en.wikipedia.org/wiki/Atomic_commit