[aosd-discuss] AOP for MVC

[Juri Memmert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Gilbertson wrote:

Hi Sean,

>     I've been trying out AOP by having it take actions from a
> controller, operate on data, and tell the controller how things
> changed.  This has been fine, but I've run into a problem: when changes
> occur in the data (outside of any trigger from the UI), I'm not sure how
> to let the controller(s) know that something has happened.  Ideally, I'd
> like to just have some way to call a method on all classes that
> implement the controller's interface (i.e. "executing" a pointcut?), but
> maybe you have a better idea?

beyond the technical solution of the problem, which Adrian has provided
some insight into, there is another issue here that you might want to
take into consideration. It's the issue how your MVC pattern looks and
acts and whether that's how the MVC should look in the first place.
- From what you describe, your controller goes active whenever some change
occurs in the UI but not when the data in the model changes.

There is a fundamental problem with this approach, since all changes
need to go through the UI to make the controller execute its logic. Thus
the communication of one MVC with another MVC or one component with the
MVC is quite hard to do since all events that the MVC is (currently)
prepared to deal with come from the view.
This, in most cases I have had to deal with MVC (your mileage may, of
course, vary) is a bad property of the MVC in question.
Most MVCs I have dealt with in the end had this kind of call graph:

	View -> Controller -> Model
	Model -> Controller ->View
	Any Other Component to change data  -> Controller -> Model
	Any Other Component to execute events -> Controller -> View

There is no way the data in the model or the state in the view can
change without the controller being informed of that BEFORE actually
setting the data.
Thus, all setters of data in the model need to notify the controller of
the new data set. All methods handling events in the view need to notify
the controller of said event.

The reason for this is that the controller contains business rules (or
delegates to a set of business rules) that make changing data or
executing certain events possible or impossible, based on some
properties that go beyond the internal mechanisms of the view or model.

If you have such a structure in place, using AOSD technologies to
perform most actions one could decide to execute on the MVC is trivial
since you'd have lots of hooks in the controller.
Without this structure in place, you do not only have to spread the
calls over the three classes, causing all sorts of problems with
comprehension and execution of calls (imho), you also have an MVC that
even without AOSD tools would not work as expected in most cases.

And for the sake of completeness... Yes, the controller becomes a large
class with a hell of a lot more methods than you normally see in a
controller and replacing a class of the MVC becomes more difficult
(adherence to contracts becomes more important), but you also gain an
MVC that actually might realize some of the advantages that MVC claims
to have in more than a simple example... but this goes far into the area
of "Criticism of OO" and doesn't have a place in the response to your
question. ;-)


	Juri


P.S. Sorry for preaching, but the use of MVC and its problems have cost
me so many hours so far, coaching people and fixing code... ;-)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCZjZSdlXiXRccbPMRAi/hAJ0c/7Yh6TpLPUdqFIfRmWM73d+TyACaA7Jj
XyUNyARCUAagKmxlz6lNDnM=
=49k1
-----END PGP SIGNATURE-----