DCI context in a web application

179 views
Skip to first unread message

Andreas Söderlund

unread,
Oct 23, 2012, 6:20:18 AM10/23/12
to object-co...@googlegroups.com
I'm thinking how and when a DCI context can be used in a Web application. I'm considering this high-level use case:
  1. User enters city, arrival, departure, room type and clicks "Search".
  2. System displays a list of hotels
  3. User clicks on a Hotel logo to read its details
  4. System displays hotel details
  5. User clicks "Book now"
  6. System displays payment form
  7. User enter customer details, billing information and clicks "Submit".
  8. System validates billing information and displays a booking confirmation.
This is very high-level and surely needs to be broken down. The first steps (1-2, 3-4, 5-6) feels like simple resource requests that could be handled with some search- and REST-architecture. So my first question is, is there a need for a DCI-context in those cases, isn't plain MVC enough? Of course a "Hotel" data entity could play a role, but would you consider it feasible, especially if it's the only actor?

The last step is where I see that DCI could be very useful, for now there is work to do in a procedural fashion. (Creating a Customer, adding a Booking to the Hotel, sending confirmation mail...)

What are your thoughts on this? Am I on the right track? Thank you for any comments!


/Andreas

rune funch

unread,
Oct 23, 2012, 6:36:54 AM10/23/12
to object-co...@googlegroups.com
I think I would say that a context starts at step 2.
You have a list of offers that plays a part. Currently those offers are hotel offers but what's a hotel offer? they might be different things. Some might be from brokers and some might be directly from hotels those are two different types of entities but they play the same part in this context, you might have many more types some which might be contexts the self. E.g. flight and hotel combined to an offer, where in that context a hotel/broker offer and a cheap flight offer plays each a role but the the listed use case you shouldn't have to worry about this but simply make it possible for the domain to evolve independently of the use case and though the use case is book cheap hotel I'd say that the form which we are trying to capture can be expressed better (though not exact) with "find best offer"

Then when picking a specific offer I'd agree that you start a new context

Best regards
Rune


2012/10/23 Andreas Söderlund <gaz...@gmail.com>


/Andreas

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/gFgXRHXOuF4J.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

Unmesh Joshi

unread,
Oct 23, 2012, 7:36:42 AM10/23/12
to object-co...@googlegroups.com
Hi Rune,

I think the way your are approaching the problem is that of a family
oriented approach. Categorizing hotel as 'offer' and then building
software to support multiple 'offerable' items like Hotel, Flight, Car
etc... can be done by commonality and variability analysis of booking
domain.
I am not sure if this is enough to categorize the problem as suitable for DCI.

Thanks,
Unmesh

Andreas Söderlund

unread,
Oct 23, 2012, 11:37:18 AM10/23/12
to object-co...@googlegroups.com
Thank you Rune, that expanded my perspective on contexts. So when I have a list of offers, how do I use that list as a Model for display in a View? I cannot return roles because they are not valid outside a Context, and I don't know what domain objects are used behind them. 

Can a View be seen as part of a context, so rendering/displaying it inside the context is valid? Or in this case when using ASP.NET MVC, returning from the Context a ViewResult with the list of offers as model. In that way the offer role is concealed in the view, but technically, I guess it still lives outside the Context that way.


/Andreas


2012/10/23 Andreas Söderlund <gaz...@gmail.com>
To unsubscribe from this group, send email to object-composition+unsub...@googlegroups.com.

rune funch

unread,
Oct 23, 2012, 1:01:03 PM10/23/12
to object-co...@googlegroups.com
Den 23/10/2012 kl. 17.37 skrev "Andreas Söderlund" <gaz...@gmail.com>:

> valid outside a Context, and I don't know what domain objects are used behind them.

Roles are identifiers so you can no more return roles than you can
return variable names. You can however return RolePlayers if that fits
the context

Andreas Söderlund

unread,
Oct 23, 2012, 1:31:26 PM10/23/12
to object-co...@googlegroups.com
Ok, so what is the difference between a Role and a RolePlayer, for example in the bank transfer example: http://horsdal.blogspot.se/2009/05/dci-in-c.html ?

rune funch

unread,
Oct 23, 2012, 1:33:58 PM10/23/12
to object-co...@googlegroups.com
if we have the following code

var myFoo = new Foo();

then we have an identifier (variable name) myFoo and some object (the result of the RHS). In DCI we have a special kind of identifier called a role and a RolePlayer is simply an object assigned a role.

-Rune

2012/10/23 Andreas Söderlund <gaz...@gmail.com>
Ok, so what is the difference between a Role and a RolePlayer, for example in the bank transfer example: http://horsdal.blogspot.se/2009/05/dci-in-c.html ?

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/LK4YJL8y9YUJ.

To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

Jason Voegele

unread,
Oct 23, 2012, 1:38:59 PM10/23/12
to object-co...@googlegroups.com
On Oct 23, 2012, at 1:33 PM, rune funch wrote:
if we have the following code

var myFoo = new Foo();

then we have an identifier (variable name) myFoo and some object (the result of the RHS). In DCI we have a special kind of identifier called a role and a RolePlayer is simply an object assigned a role.

But is it not the case that what you call a role is more than just an identifier or variable name because it has some code or algorithm associated with it? For instance, the many transfer example has a role named "Source" (within the MoneyTransfer context), but this role is more than just a name because it has Withdraw and Transfer methods contained within it.

-- 
Jason Voegele
Never be led astray onto the path of virtue.

rune funch

unread,
Oct 23, 2012, 1:42:21 PM10/23/12
to object-co...@googlegroups.com


2012/10/23 Jason Voegele <jason....@gmail.com>
Yes it is the case which is what makes it a role and not just another variable but it's still "just" an identifier. It identifies the RolePlayer when the contexst executes and it identifies the RoleMEthods associated with the RolePlayer (while playing the role)

-Rune

 

-- 
Jason Voegele
Never be led astray onto the path of virtue.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

James O Coplien

unread,
Oct 23, 2012, 1:55:32 PM10/23/12
to object-co...@googlegroups.com
Andreas Söderlund is playing the role of a mailing group member.

Andreas Söderlund is, at his foundation, a lump of DNA.

A mailing group member, in the current Context of dialogues, exhibits behaviors of asking questions through mails.

What is the difference between a mailing group member and Andreas Söderlund? In the context of the current Context: nothing. In general, equating them is a category error.


On Oct 23, 2012, at 10:31 , Andreas Söderlund wrote:

Ok, so what is the difference between a Role and a RolePlayer, for example in the bank transfer example: http://horsdal.blogspot.se/2009/05/dci-in-c.html ?


--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.

Raoul Duke

unread,
Oct 23, 2012, 2:56:05 PM10/23/12
to object-co...@googlegroups.com
in other words: role = interface, roleplayer = concrete implementer of
interface.

?

rune funch

unread,
Oct 23, 2012, 3:49:11 PM10/23/12
to object-co...@googlegroups.com
Den 23/10/2012 kl. 20.56 skrev Raoul Duke <rao...@gmail.com>:

> in other words: role = interface, roleplayer = concrete implementer of
> interface
A role is not an interface any more than a variable name is an
interface for the object it represents at runtime. A role is an
identifier it identifies a RolePlayer and the role specific behavior
of said RolePlayer. Interfaces are a subset of types. Identifiers are
not.
This is a form of class thinking. In DCI we are more concerned with
objects that types. Roles tells us something about the objects
behavior at runtime but nothing about its type whereas interfaces
tells us something about the type at compile type but little about the
type of the object at runtime

Raoul Duke

unread,
Oct 23, 2012, 4:12:52 PM10/23/12
to object-co...@googlegroups.com
On Tue, Oct 23, 2012 at 12:49 PM, rune funch <funchs...@gmail.com> wrote:
> This is a form of class thinking. In DCI we are more concerned with
> objects that types. Roles tells us something about the objects
> behavior at runtime but nothing about its type whereas interfaces
> tells us something about the type at compile type but little about the
> type of the object at runtime

different semantics, connotations, for the terms used?

if you mean e.g. roles are structural types and not nominal, you'd
still have the word 'type; involved. :-)

er, unless you are really trying to come up with new ways to have even
more runtime exceptions than the run of the mill "dynamic" "scripter"
programmer. :-)

Risto Välimäki

unread,
Oct 23, 2012, 4:20:58 PM10/23/12
to object-co...@googlegroups.com
Not semantics, but roles are not types at all.

You mean role contracts here. Role contracts may be types. Role contract is more or less an "interface" that an object has to fullfil to be able to play a certain role in a certain context.

-Risto

2012/10/23 Raoul Duke <rao...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "object-composition" group.

Raoul Duke

unread,
Oct 23, 2012, 4:27:52 PM10/23/12
to object-co...@googlegroups.com
On Tue, Oct 23, 2012 at 1:20 PM, Risto Välimäki
<risto.v...@gmail.com> wrote:
> Not semantics, but roles are not types at all.
> You mean role contracts here. Role contracts may be types. Role contract is
> more or less an "interface" that an object has to fullfil to be able to play
> a certain role in a certain context.

so Role Contract is the in-the-code implementation artifact of the
outside-the-computer generalized domain idea of Role? like you can use
Role in engrish w/out having to mention anything about computers.

rune funch

unread,
Oct 23, 2012, 4:39:31 PM10/23/12
to object-co...@googlegroups.com


2012/10/23 Raoul Duke <rao...@gmail.com>

if you mean e.g. roles are structural types and not nominal, you'd
still have the word 'type; involved. :-)
No I mean that they are not a type but an identifier. Being an identifier a role is no more a type than a variable name or a parameter is a type.
 
so Role Contract is the in-the-code implementation artifact 
Role contracts are not something you implement. In certain languages (such as Marvin) they can be specified. 
It's a contract that an object must fulfill to be able to play a specific role. Not doing so will lead to a compile time or runtime error (depending on the language used). (Method not implemented)

Risto Välimäki

unread,
Oct 23, 2012, 4:40:12 PM10/23/12
to object-co...@googlegroups.com
If I understood correctly, no.

But with real world language:

Edwin Booth was an actor, an Object.

Hamlet is a Role in play Hamlet, which is the Context here.

Hamlet WAS not Edwin Booth and Edwin Booth WAS not Hamlet.

Still Edwin Booth had all what is needed to Play Role of Hamlet in Hamlet Context.
In another words, Edwin Booth fulfilled the Role contract for Role Hamlet in Hamlet Context.

Also Edwin Booth actually played successfully Role of Hamlet in Hamlet Context, so he really was a Role player.

I hope this helps.

-Risto


2012/10/23 Raoul Duke <rao...@gmail.com>
On Tue, Oct 23, 2012 at 1:20 PM, Risto Välimäki

Risto Välimäki

unread,
Oct 23, 2012, 4:48:05 PM10/23/12
to object-co...@googlegroups.com
I think I have to add notion on Role methods here, because that may be an another source of confusion:

While Roles are only identifiers, inside Contexts there are usually Role methods which are Just-On-Time -- temporarily -- attached to Roleplayers which are identified by Roles.

But while Role methods they are attached to Roleplayers (that are identified by Roles), you can never return a Roleplayer with Role methods attached from a Context to another. If your implementation style (injectionless, method injection, wrapper, etc.) allows that, you are in serious problems.

-Risto

2012/10/23 Risto Välimäki <risto.v...@gmail.com>

Rickard Öberg

unread,
Oct 23, 2012, 10:24:53 PM10/23/12
to object-co...@googlegroups.com
On 10/23/12 18:20 , Andreas S�derlund wrote:
> I'm thinking how and when a DCI context can be used in a Web
> application. I'm considering this high-level use case:
>
> 1. User enters city, arrival, departure, room type and clicks "Search".
> 2. System displays a list of hotels
> 3. User clicks on a Hotel logo to read its details
> 4. System displays hotel details
> 5. User clicks "Book now"
> 6. System displays payment form
> 7. User enter customer details, billing information and clicks "Submit".
> 8. System validates billing information and displays a booking
> confirmation.
>
> This is very high-level and surely needs to be broken down. The first
> steps (1-2, 3-4, 5-6) feels like simple resource requests that could be
> handled with some search- and REST-architecture. So my first question
> is, is there a need for a DCI-context in those cases, isn't plain MVC
> enough? Of course a "Hotel" data entity could play a role, but would you
> consider it feasible, especially if it's the only actor?

The way I've done it in webapps, the logic is implemented by a REST API
that only uses DCI for its implementation. Each /foo/ becomes a context,
and within that context is a number of queries and commands (e.g.
/foo/search and /foo/book, note the lack of / here which indicates that
it is not a usecase but an interaction), which can lead to subcontexts
/foo/bar/, having its own queries and commands. From the root / you
would then get hypermedia showing all usecases, and then from each /foo
you get hypermedia with links to what you can do within that usecase,
and that can then be used to drive the application state, just as Roy
intended it. It is teh awesome, and suddenly this whole linking thing
becomes obvious. A good REST API should be like an ugly website, is my
rule of thumb.

One the client side you can then either have a webapp that uses MVC, or
a rich client in Javascript or whatever that uses this. I've done both,
and the unified REST backend really helps.

/Rickard

James O Coplien

unread,
Oct 23, 2012, 11:13:33 PM10/23/12
to object-co...@googlegroups.com

On Oct 23, 2012, at 1:20 , Risto Välimäki wrote:

Not semantics, but roles are not types at all.


I guess it depends what you mean by "type." I think they are indeed types. Why don't you?

rune funch

unread,
Oct 24, 2012, 1:29:21 AM10/24/12
to object-co...@googlegroups.com
Den 24/10/2012 kl. 05.10 skrev James O Coplien <jcop...@gmail.com>:


On Oct 23, 2012, at 1:20 , Risto Välimäki wrote:

Not semantics, but roles are not types at all.
Because the use of the term 'type' that most people have do not coincide with the use used in type theory. Conceptually you don't instantiate roles nor can you cast an object to 'Role x'. In some language that do not support DCI that well you will have to but that because you have to not because the role concept enforces this ability. 
When assigned to a role the type of the object changes but this new type is a union of the type of the object and the role is neither on their own. I find that trying to use the more academic version of 'type' though correct confuses more that it helps because it is more likely to keep people in class based thinking




I guess it depends what you mean by "type." I think they are indeed types. Why don't you?

--

try...@ifi.uio.no

unread,
Oct 25, 2012, 2:23:30 PM10/25/12
to object-co...@googlegroups.com
A view is an object, so a view can play a role. In othe view role metho
actually updates the view, This is more direct than using the observer
pattern, for example.
>> 2012/10/23 Andreas S�derlund <gaz...@gmail.com <javascript:>>
>>
>>> I'm thinking how and when a DCI context can be used in a Web
>>> application.
>>> I'm considering this high-level use case:
>>>
>>> 1. User enters city, arrival, departure, room type and clicks
>>> "Search".
>>> 2. System displays a list of hotels
>>> 3. User clicks on a Hotel logo to read its details
>>> 4. System displays hotel details
>>> 5. User clicks "Book now"
>>> 6. System displays payment form
>>> 7. User enter customer details, billing information and clicks
>>> "Submit".
>>> 8. System validates billing information and displays a booking
>>> confirmation.
>>>
>>> This is very high-level and surely needs to be broken down. The first
>>> steps (1-2, 3-4, 5-6) feels like simple resource requests that could be
>>> handled with some search- and REST-architecture. So my first question
>>> is,
>>> is there a need for a DCI-context in those cases, isn't plain MVC
>>> enough?
>>> Of course a "Hotel" data entity could play a role, but would you
>>> consider
>>> it feasible, especially if it's the only actor?
>>>
>>> The last step is where I see that DCI could be very useful, for now
>>> there
>>> is work to do in a procedural fashion. (Creating a Customer, adding a
>>> Booking to the Hotel, sending confirmation mail...)
>>>
>>> What are your thoughts on this? Am I on the right track? Thank you for
>>> any comments!
>>>
>>>
>>> /Andreas
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "object-composition" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/object-composition/-/gFgXRHXOuF4J.
>>> To post to this group, send email to
>>> object-co...@googlegroups.com<javascript:>
>>> .
>>> To unsubscribe from this group, send email to
>>> object-composit...@googlegroups.com <javascript:>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/object-composition?hl=en.
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "object-composition" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/object-composition/-/les30SNaDcAJ.
> To post to this group, send email to object-co...@googlegroups.com.
> To unsubscribe from this group, send email to
> object-composit...@googlegroups.com.

try...@ifi.uio.no

unread,
Oct 25, 2012, 2:47:58 PM10/25/12
to object-co...@googlegroups.com
I am learning to use i-pad. Default automatic error correction was on, so
it tried to change my English words into Norwegian. This feature is now
off, so I try again.

A view is an objext, so it can play a role. Indeed, inone of my examples
I let the view role method update the view. Much more direct than using
the observer pattern, for example.

>> 2012/10/23 Andreas S�derlund <gaz...@gmail.com <javascript:>>
>>
>>> I'm thinking how and when a DCI context can be used in a Web
>>> application.
>>> I'm considering this high-level use case:
>>>
>>> 1. User enters city, arrival, departure, room type and clicks
>>> "Search".
>>> 2. System displays a list of hotels
>>> 3. User clicks on a Hotel logo to read its details
>>> 4. System displays hotel details
>>> 5. User clicks "Book now"
>>> 6. System displays payment form
>>> 7. User enter customer details, billing information and clicks
>>> "Submit".
>>> 8. System validates billing information and displays a booking
>>> confirmation.
>>>
>>> This is very high-level and surely needs to be broken down. The first
>>> steps (1-2, 3-4, 5-6) feels like simple resource requests that could be
>>> handled with some search- and REST-architecture. So my first question
>>> is,
>>> is there a need for a DCI-context in those cases, isn't plain MVC
>>> enough?
>>> Of course a "Hotel" data entity could play a role, but would you
>>> consider
>>> it feasible, especially if it's the only actor?
>>>
>>> The last step is where I see that DCI could be very useful, for now
>>> there
>>> is work to do in a procedural fashion. (Creating a Customer, adding a
>>> Booking to the Hotel, sending confirmation mail...)
>>>
>>> What are your thoughts on this? Am I on the right track? Thank you for
>>> any comments!
>>>
>>>
>>> /Andreas
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "object-composition" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/object-composition/-/gFgXRHXOuF4J.
>>> To post to this group, send email to
>>> object-co...@googlegroups.com<javascript:>
>>> .
>>> To unsubscribe from this group, send email to
>>> object-composit...@googlegroups.com <javascript:>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/object-composition?hl=en.
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "object-composition" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/object-composition/-/les30SNaDcAJ.
> To post to this group, send email to object-co...@googlegroups.com.
> To unsubscribe from this group, send email to
> object-composit...@googlegroups.com.

Unmesh Joshi

unread,
Nov 3, 2012, 7:52:55 AM11/3/12
to object-co...@googlegroups.com
I was going through this thread again. And I think that the answers to
original questions were not specific. Considering 'hotel', 'flight'
etc.. as offers is a standard solution of the product owner building
the website wants customers to book various things related to his/her
trip (Hotel, Flight, Cars, Cruise etc..). Finding commonality and
variabilities in all the offerable items and then chosing code
constructs to fit types of variabilities is a problem that can be
solved without DCI. Standard generalization/specilization and other
techniques of classical OO will solve that problem. (A rule of thumb
is to remove if-else with message passing to objects).

DCI helps specifically in cases where there is commonality in
behaviour. Methodful Roles capture commonality in algorithms and then
object behavioral contract is composed by assigning roles to object in
a specific use case context.

The use case in the original question what a very high level (summary
level) use case. I dont see any methodful roles in this particular use
case. Nor can I see any role specific behaviour. So it is too early
to say if we can apply DCI to this specific use case. Please correct
me if I am missing something.

Thanks,
Unmesh

rune funch

unread,
Nov 3, 2012, 11:26:10 AM11/3/12
to object-co...@googlegroups.com
Den 03/11/2012 kl. 12.52 skrev Unmesh Joshi <unmes...@gmail.com>:

> So it is too early
> to say if we can apply DCI to this specific use case. Please correct
> me if I am missing something
Any network of Interacting objects can be modeled as a context. So we
can use DCI

Eric Steen

unread,
Nov 3, 2012, 12:10:27 PM11/3/12
to object-co...@googlegroups.com, object-co...@googlegroups.com
Just to throw an example out there..

In the authentication context, a User might interact with an Authenticator. In the post commenting context, a user may interact with PostCommentPublisher(who may interact with an editor-- and editor may interact with a ProfanityMasker).

The corresponding metaphors could be a guard at an office building who checks your identity before allowing access, and a traditional publishing house with its various roles.

Sent from my iPhone

James O Coplien

unread,
Nov 3, 2012, 1:18:18 PM11/3/12
to object-co...@googlegroups.com

On Nov 3, 2012, at 5:10 , Eric Steen wrote:

> In the authentication context, a User might interact with an Authenticator. In the post commenting context, a user may interact with PostCommentPublisher(who may interact with an editor-- and editor may interact with a ProfanityMasker).


These sound a bit like functors rather than roles. Other than "Authenticate," what are the methods of an Authenticator?

As someone who has written many books I can tell you I have never met an Authenticator, PostCommentPublisher or a ProfanityMasker. Authenticate and ProfanityMasking may be tasks of an Editor. There's at least some kind of mismatch going on between your mental model and mine, and the mismatch may extend into your embracing of the DCI paradigm, but I'm not sure.


Eric Steen

unread,
Nov 3, 2012, 2:49:46 PM11/3/12
to object-co...@googlegroups.com, object-co...@googlegroups.com
Other than "Authenticate," what are the methods of an Authenticator?

Perhaps the Authenticator assumes the role of an oauthable(social auth). Given those behaviors it can auth via social media?

Sent from my iPhone

James O Coplien

unread,
Nov 3, 2012, 3:43:20 PM11/3/12
to object-co...@googlegroups.com

On Nov 3, 2012, at 7:49 , Eric Steen wrote:

Other than "Authenticate," what are the methods of an Authenticator?

Perhaps the Authenticator assumes the role of an oauthable(social auth). Given those behaviors it can auth via social media?

This is an imprecise answer and I can't place it in a DCI context. Are you saying that a role takes the role of another role? 

Eric Steen

unread,
Nov 3, 2012, 3:55:26 PM11/3/12
to object-co...@googlegroups.com, object-co...@googlegroups.com

This is an imprecise answer and I can't place it in a DCI context. Are you saying that a role takes the role of another role? 

Probably just a bad example. I was assuming that Authenticator object was the actualizer of a Use Case(a context), which acted upon the User( a dumb data object). Maybe if I give Authenticator a name like AuthenticationContext it is clearer?

Sent from my iPhone

James O Coplien

unread,
Nov 3, 2012, 7:46:26 PM11/3/12
to object-co...@googlegroups.com

On Nov 3, 2012, at 8:55 , Eric Steen wrote:

Probably just a bad example. I was assuming that Authenticator object was the actualizer of a Use Case(a context), which acted upon the User( a dumb data object). Maybe if I give Authenticator a name like AuthenticationContext it is clearer?

Precision and clarity are worth their weight in gold here. Code doesn't lie (if it compiles). Can you give a code example?


Reply all
Reply to author
Forward
0 new messages