5

All the examples of DCI I've seen seems to be based on the object as the ultimate holder of information, and the transaction boundaries are defined inside the methods.

I would like to see an example of a persistent application, where there is some sort of persistence layer, i.e. where there can be duplicate object copies of the underlying persistence storage and where a change to an object is a change to a copy that will later be persisted. Does DCI work for that model at all?

nilskp
  • 3,097
  • 1
  • 30
  • 34
  • any application that can be implemented with OO can be implemented with DCI. DCI _is_ OO but enforces constraints to how to do OO. That said there are no objects in a persistence layer, nor are there "copies of an object" there are classes in a persistence layer and multiple objects representing the same information. DCI is not concerned with classes (they are a language feature) and syncronizing different representations of what's suppossed to be the same is an issue ortogonal to all paradigms that accept side effects (and can be solved in various ways in them all too) – Rune FS Sep 13 '13 at 08:49

3 Answers3

3

DCI is a paradigm and just as you can build an application using any other paradigm with persistence (execluding pure FP since persistence is a side effect) so can you with DCI. It's not mentioned in DCI examples because it's not a concern to the paradigm and is unrelated to understanding the paradigm. (That said you're not the first to ask the question and will not be the last I'm sure).

The concern of persisting data is in general ortogonal to DCI. DCI tries to partition the design into

  • What the system is
  • What the system does

The first is the domain model and the second is the functionality of the system. Whether "what the system is" is kept in memory, flat files or a DB is important of course but a separate concern and is usually implemented using restricted OO

Rune FS
  • 21,497
  • 7
  • 62
  • 96
  • What you say makes sense, but I think the reason it's brought up so often is that e.g. in the Artima article, there's explicit use of transaction boundaries. This implies something about persistence and as such leaves people with the question. – nilskp Mar 05 '12 at 19:47
  • @nilskp agreed and that's where restrict OO comes in. Most DCI examples omit the restricted OO parts for brevity. I'm in different boat than some of those examples since I tend to use DCI one a lower level than the examples just as Guge mentions in a comment I'm might very well use DCI in the persistence "layer" – Rune FS Mar 14 '12 at 12:29
2

DCI doesn't really concern itself with persistance.

Guge
  • 4,569
  • 4
  • 35
  • 47
  • What does that mean? That it's an orthogonal concern, i.e. DCI is outside that scope, because it doesn't matter? Or it's a valid concern that is just not addressed by DCI? – nilskp Aug 27 '10 at 12:54
  • 2
    Persistance is always a valid concern, but DCI is more of a paradigm than an architecture. So I think it's orthogonal. DCI has a lot to say about data, but not so much where it comes from or where it goes. I guess you could even use DCI in your persistance layer, in the sense that persisting data is a use-case that begins when the user selects File/Save from the menu. – Guge Aug 27 '10 at 14:38
1

At http://blog.maxant.co.uk/pebble/files/dci_java_example_for_object_composition_google_group_201010052226.zip I have posted an example in Java, which incorporates JPA (ORM) for persisting entities.

It's part of a white paper to be posted soon at www.maxant.co.uk/whitepapers.jsp

A further example showing DCI being integrated into an app server will be in that paper. Hope that helps!

Ant Kutschera
  • 6,257
  • 4
  • 29
  • 40