lib/Reaction/Manual/Intro.pod

   1 =head1 NAME
   2
   3 Reaction::Manual::Intro - Introduction to Reaction
   4
   5 =head1 SYNOPSIS
   6
   7   Moose + Catalyst + Layered Models = eternal happiness
   8
   9 =head1 MOTIVATION
  10
  11 While L<Catalyst> is a very powerful and flexible web app
  12 framework, many pieces end up being recoded for each
  13 new application: user interfaces, in particular.
  14
  15 Meanwhile, advances in Perl metaprogramming (especially L<Moose>)
  16 have opened up new possibilities in terms of introspection.
  17 Why not build user interfaces based on class metadata?
  18 This would allow the user interface templates to be very general
  19 where possible.
  20
  21 Thus, Reaction is basically an extended MVC framework, which
  22 leverages class metadata to reduce or eliminate UI coding.
  23
  24 But it's much more....
  25
  26 =head1 DOMAIN MODELS AND INTERFACE MODELS
  27
  28 Many programmers are now comfortable using ORMs of one sort or
  29 another - L<DBIx::Class>, L<Class::DBI>, Hibernate, etc.  These systems
  30 are wonderful for bridging from the world of OO into the world of relational
  31 databases (or other datastores).  This model is sometimes called a
  32 "domain model", because it models the "nouns" of a problem domain in
  33 the real world.  Domain models are easily shared accross applications,
  34 and can enforce validation and other integrity constraints.
  35
  36 However, over time, many application developers find themselves adding
  37 business logic to the domain model.  This business logic is often
  38 application-specific, and reduces the reusability of the domain model.
  39 Worse, business logic becomes spread between the model and the contoller.
  40
  41 Reaction adds another layer, the Interface Model.  Interface models provide an
  42 adaptor to the domain model, customized for a particular application (or group
  43 of use cases).  This decouples the domain model from the application,
  44 allowing it to be reused more freely.  Additionally, the Interface Model
  45 becomes the natural location for business logic.
  46
  47 Happily, Reaction again uses reflection to make the degenerate case easy - when your
  48 IM has no customized functionality, it can simply delegate all work to the DM.  When
  49 you need to add custom business logic, you can add or replace functionality as needed.
  50
  51 The DM/IM split is sometimes referred to as a FacadeModel - see
  52 L<http://www.twinforces.com/tf/docs/MFCV.html>, for example.
  53
  54 =head1 WHAT YOU'LL NEED TO KNOW
  55
  56 Reaction is based on the L<Catalyst> web application framework.  You'll certainly
  57 need to be familiar with L<Catalyst::Manual::Intro>.
  58
  59 Currently, only L<DBIx::Class> is supported as a domain model.  At least basic
  60 familiarity will be needed. L<DBIx::Class::Manual::Intro> is a good starting point.
  61
  62 The default view renderer is L<Template::Toolkit>.  To edit your views, you'll
  63 need to know something about it.
  64
  65 While you don't need to know L<Moose> directly, a lot of the concepts of
  66 metaprogramming will keep coming up as you work with Reaction.
  67 Thus, getting to know L<Moose> will serve you well.
  68
  69 =head1 NEXT STEPS
  70
  71 The L<Reaction::Manual::Overview> document tries to tie the parts of reaction
  72 together to form a big picture.
  73
  74 If you'd like an example, see L<Reaction::Manual::Example>.
  75
  76 If you're ready to dive in and start learning step by step, see
  77 L<Reaction::Manual::Tutorial>.
  78
  79 As you encounter unfamiliar terms, or want to see how a particular term is used in the
  80 context of the Reaction project, refer to the L<Reaction::Manual::Glossary>.
  81
  82 =head1 SEE ALSO
  83
  84 =over
  85
  86 =item * L<Reaction::Manual::Cookbook>
  87
  88 =item * L<Reaction::Manual::FAQ>
  89
  90 =back
  91
  92 =head1 AUTHORS
  93
  94 See L<Reaction::Class> for authors.
  95
  96 =head1 LICENSE
  97
  98 See L<Reaction::Class> for the license.
  99
 100 =cut