Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.help > #1655

Re: Validating form inputs?

From Arved Sandstrom <asandstrom3minus1@eastlink.ca>
Newsgroups comp.lang.java.help
Subject Re: Validating form inputs?
References <ed7f31e9-8a19-46c7-9a7c-ad8aabfb9599@x10g2000pbi.googlegroups.com> <cdthm7h8ouvn55aoeah597mjjse0j7mrkh@4ax.com> <eodim79a4ms63j0nsbhk4bf7472hr96oqg@4ax.com> <C1rar.3066$qw7.1550@newsfe08.iad> <ldikm7tdub1buota9v60srv2gko7fbio58@4ax.com>
Message-ID <Y_sar.31206$M%7.10412@newsfe10.iad> (permalink)
Organization Public Usenet Newsgroup Access
Date 2012-03-21 19:54 -0300

Show all headers | View raw


On 12-03-21 06:46 PM, Gene Wirchenko wrote:
> On Wed, 21 Mar 2012 17:41:05 -0300, Arved Sandstrom
> <asandstrom3minus1@eastlink.ca> wrote:
> 
> [snip]
> 
>> One of the tensions in OOP is where to put algorithmic code, or use-case
>> type of code, or controller type of code. The DDD (domain-driven design)
> 
>       DINGDINGDINGDINGDING!
> 
>> folks would have it that domain objects have to be rich, with
>> practically all behaviours finding a home in methods of one domain
>> object or another. In this picture the classes in the
>> service/application layer are supposed to be seriously lightweight, with
>> little or no business logic.
> 
>      If I have clearly-defined entities that I can make classes for, I
> will do so.  If I do not have that, I avoid proper classes.  At the
> very least, I then avoid the clutter of unnecessary classes.
> Consequently, my classes tend to be fairly heavyweight, or they are
> little more than wrappers.
> 
>> This has been proven not to work in the real world, time and time and
>> time again. Inevitably there is a great deal of procedural, algorithmic
>> code that expresses *use case* logic and doesn't belong in domain
>> classes. So people - and I include myself in that large number - do what
>> you've described; they put this type of code in methods in "procedural"
>> classes. Call 'em controllers or services or whatever you like, that's
>> what they are - procedural.
> 
>      I consider OOP to be procedural.  The difference is how the
> procedures get called.
> 
>> We've tried the rich domain object approach ad nauseam, and good useful
>> system behaviour does *not* just "emerge" from those domain objects.
>> Most of the "what the system _does_" behaviour needs to be captured
>> outside domain classes, which latter should be reserved for "what the
>> system _is_" behaviour + domain state.
> 
>      Inform is a language for writing interactive fiction (a.k.a. text
> adventures).  Version 6 is very OOP.  (Version 7 went in a different
> direction.)  From what I have read, it can get very messy deciding
> where implementation code goes.  For example, where should the code go
> to tie a rope to something?  Properties of both the rope and the other
> object will be checked.
> 
>> I've mentioned DCI (Data Context Interaction) before, and I'll mention
>> it again. You may not buy into it completely or much at all, and it's
>> not easy to implement in Java actually [1], but it's one of the few
>> methodologies that recognizes the fact that a lot of behaviour doesn't
>> fit into domain objects, doesn't belong in domain objects, and there
>> needs to be a systematic approach as to where to put it. Hence contexts
>> that orchestrate the components that belong to a use case, with
>> behavioural code (methods) being injected by some mechanism into barely
>> smart domain objects.
>>
>> Here ends my little pro-DCI rant for the day.
> 
>      Could you please give a URL to something that explains the
> basics?
> 
>> AHS
>>
>> 1. Serious investigation of DCI rates the use of Ruby or Scala or C++
>> (or even C# - extension method approach), whatever you're most
>> comfortable with. Once you've got the general ideas down, then you can
>> try Qi4J in Java. Just my opinion as to how to tackle things.
> 
> Sincerely,
> 
> Gene Wirchenko

At some point you pretty much have to read the seminal article:
http://www.artima.com/articles/dci_vision.html.

It helps to read this again from time to time as you experiment. Also,
the example they use (which has become semi-canonical) sucks, in my
opinion. They could have done considerably better. It can also be
worthwhile to peruse the discussion (click on the Discuss link at the
bottom).

This Groovy-based article is quite good:
http://victorsavkin.com/post/4243788839/dci-in-groovy

For further material follow from
http://stackoverflow.com/questions/3879348/examples-of-dci-architecture.
From that batch the article at
http://pettermahlen.com/2010/09/10/dci-architecture-good-not-great-or-both/
is quite good; he asks some good questions and isn't blindly accepting
of everything.

One of the main ideas behind DCI is to make the algorithm a first class
citizen, or as much as you can in your particular language. Rather than
having the business logic that pertains to the next button click in your
MVC web app be scattered all over several dozen methods in 5 or 10
classes, not to mention each class being a grab bag of methods to handle
every possible situation that the object of said class has to
participate in, business logic ends up in "role" methods that are
assigned to much leaner domain objects by the context depending on the
specific use case.

DCI is about *object* oriented programming, not about class oriented
programming. I actually bleat on about this at
http://exvalle.blogspot.ca/2012/03/more-notes-on-dci.html

AHS
-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

Back to comp.lang.java.help | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Validating form inputs? Davej <galt_57@hotmail.com> - 2012-03-20 11:16 -0700
  Re: Validating form inputs? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-20 12:08 -0700
    Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-20 12:50 -0700
      Re: Validating form inputs? markspace <-@.> - 2012-03-21 09:24 -0700
      Re: Validating form inputs? Davej <galt_57@hotmail.com> - 2012-03-21 12:02 -0700
        Re: Validating form inputs? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-21 12:59 -0700
        Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-21 13:37 -0700
    Re: Validating form inputs? Davej <galt_57@hotmail.com> - 2012-03-20 12:56 -0700
      Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-20 13:58 -0700
      Re: Validating form inputs? markspace <-@.> - 2012-03-21 09:30 -0700
  Re: Validating form inputs? Roedy Green <see_website@mindprod.com.invalid> - 2012-03-20 14:28 -0700
    Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-20 19:16 -0700
      Re: Validating form inputs? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-21 17:41 -0300
        Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-21 14:46 -0700
          Re: Validating form inputs? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-21 19:54 -0300
        Re: Validating form inputs? Roedy Green <see_website@mindprod.com.invalid> - 2012-03-22 10:34 -0700
      Re: Validating form inputs? Lew <lewbloch@gmail.com> - 2012-03-21 14:56 -0700
        Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-21 19:09 -0700
          Re: Validating form inputs? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-22 08:36 -0700
            Re: Validating form inputs? Gene Wirchenko <genew@ocis.net> - 2012-03-22 09:40 -0700

csiph-web