MVC, MV, Controllers and ActivityAgents: Why bother?

[ConvertFromOldNGs]

by Eric Peachey >> Wed, 5 Apr 2000 4:44:48 GMT

Hello,

What the experienced O-O JADE gurus out there have to say about the value of using ActivityAgents, Controllers etc when building JADE systems?

What advantages do they offer?
What disadvantages do they bring?
What approach do use in your systems?
What's your experience of MV/MVC in JADE been like?
Added all your updates to forms and wish you hadn't?
Do you find that they really are re-usable?
If you were building simple JADE systems would you bother?

The JADE Discovery Kit describes reasons for the MV architecture. Just wondering what your experiences in the real JADE world have revealed.

Thanks for your input,

Eric in Dunedin

[ConvertFromOldNGs]

by Frank Pitt >> Thu, 6 Apr 2000 4:38:28 GMT

What the experienced O-O JADE gurus out there have to say about the value of using ActivityAgents, Controllers etc when building JADE systems?

What advantages do they offer?

At a minimum, the benefits obtained from being able to test and validate your logic independantly of the UI are major.

Add to that the greater deployment flexibility, ( business logic can be deployed in different tiers, and can be used in different applications ) and for any serious application it is definitely worthwhile.

What disadvantages do they bring?

The major "disadvantage" is that extra layer of indirection,
You write more "population of the UI" or "extract data from the UI" code than you might otherwise.

Some things that might be easily validated inside the UI might take longer to validate with remote business logic.

Best way to handle this IME is to carefully decide what is business logic and what is
input validation, and keep simple generic input validation on the UI.

For instance, if the field is supposed to accept a date, check that it's a valid date before you bother going to the business logic layer. If you have to check that the date is greater than another date in the your model, that's business logic and should be a part of the model.

This may lead to duplication of the validation code. Personally I don't care, I don;t see a problem with checking something twice, imortant things should probably be checked more often, but it might have a performance effect so needs to be thought about.

What approach do use in your systems?

My normal procedure is write the logic, and test it from the command line the equivalent in JADE would be from a workspace or JadeScript), before even looking at creating a UI for it. So many mistakes are made by people who start with UI and work from there...

That's not to say that a UI prototype shouldn't be started at the same time, to explore possible designs, but it should be explicitly made a throwaway, if neccessary put some huge flaw in it on purpose, to ensure people don't want you to keep using it.

What's your experience of MV/MVC in JADE been like?

Small. see below.

Added all your updates to forms and wish you hadn't?

I've seen people do this in the past, and have done it myself in early Visual Basic applications. I quickly got out of the habit. <grin>

Do you find that they really are re-usable?

Yes. Some more than others though.

If you were building simple JADE systems would you bother?

Simple, as in a couple of forms, intended to never be expanded, perhaps.

But even then, the number of times people take what were simple systems and keep asking for more features.... These days, unless it was for demonstration purposes only, I'd always seperate logic from UI, just in case I had to come back and work on it again.

The JADE Discovery Kit describes reasons for the MV architecture. Just wondering what your experiences in the real JADE world have revealed.

Not having any "real world" experience in JADE, you'll have to take this with a pinch of salt, but what I've said comes from a pile of experience in C, C++, & Java, and a tiny amount of SmallTalk.

(Yes we use MVC in C too, early Windows programs had to be written in C, and the Motif and X libraries were all C to.)

I don't consider that system architecture should be any different for JADE, such things are pretty much implementation independant IME.

Frankie

[ConvertFromOldNGs]

by cnwep1 >> Fri, 7 Apr 2000 10:59:19 GMT

Well Frankie I'm still not convinced.

At a minimum, the benefits obtained from being able to test and validate your logic independantly of the UI are major.

Imagine you don't have a 'controller' and just methods on a form. You can just as easily set properties on a form in a JadeScript method (say) as you can properties on a non-GUI object.

Add to that the greater deployment flexibility, ( business logic can be deployed in different tiers, and can be used in different applications ) and for any serious application it is definitely worthwhile.

Not sure what you mean by 'deployment': if you mean 'distribution' then that's not really an issue with Jade is it?

Use in different applications: If you can identify that you're going to need the same behaviour in more than one place then I can see some use of putting that behaviour on a controller class. Is it really worth the overhead of separating things just because you might possibly need to use it somewhere else for some imaginary situation in the future?

The major "disadvantage" is that extra layer of indirection, You write more "population of the UI" or "extract data from the UI" code than you might otherwise.

More code = more testing = more to go wrong = more to change = more $.

Some things that might be easily validated inside the UI might take longer to validate with remote business logic.

Not sure what you mean by 'remote business logic'. Chances are that a validation controller object is sitting in your transient cache and there'd be no trip to the server. This is JADE we're talking about not some complicated multi-tool environment.


What do some other gurus say about layering:

Fowler on the Advantages of the Presentation/Application logic split in 'Analysis Patterns':

"Layering is a good idea in principle, but it does have some disadvantages: the extra work is required to build the layer, and a performance penalty can be incurred in using it. The important question is, are the advantages worth the costs?"

He goes on to say that "One advantage comes from the different styles of programming involved in the two layers." With Jade this isn't an issue as the whole system is built using a single tool.

He also argues that "When facade (read ActivityAgent/Controller) and presentation are combined, the base computation can only be tested via the GUI, requiring manual testing" In Jade a form is just another kind of object and can be manipulated like any other if necessary.


And our mates from Scandiwegia (Jacobson OOSE A UseCase driven Approach):
"In fact, we can build any system with just these two object types (interface and entity). However, when such a model has been developed, you will notice that there are certain behaviours that are not naturally placed, from a maintainability view, in either entity objects or interface objects; or even worse, they are spread over several objects." Okay, it's a fair cop guvna.

They say one of the dangers of using control objects:

"Beginners sometimes only use entity objects as data carriers and place all dynamic behaviour in control objects. This should, however be avoided. Using this extreme, we will end up with a function/data structure" I've seen this in a system using agents/controllers. Whereas in systems with interface and entity classes the entities seem to do a lot of validation.

Craig Larman in "Applying UML and Patterns" says:

"Motivations for a multi-tiered architecture include:
a) Isolation of application logic into separate components which can be reused in other systems.
b) Distribution of tiers on different physical computing nodes, and/or different processes. This can improve performance and increase coordination and shared information in a client-server system.
c) Allocation of developers to construct specific tiers, such as a team working solely on presentation layer. This supports specialized expertise in terms of development skills, and the ability to run parallel team ddddevelopment efforts."

As far as I can see from the above only (a) might apply in Jade and even then the classes will be so specialised the opportunity for reuse must be slight.


All the received wisdom on the subject I've seen seems to relate to toolsets and environments quite different to JADE. Perhaps we can cut a few corners and get away with it. I can see that occasionally you will benefit from employing some kind of controller class but using them unnecessarily just because it's the fashion can't be productive.

Eric in Waitati (dark and misty and my dog wants to go for a wee)

[ConvertFromOldNGs]

by Darrell Duniam >> Sat, 8 Apr 2000 3:18:03 GMT

Well Frankie I'm still not convinced.

At a minimum, the benefits obtained from being able to test and validate your logic independantly of the UI are major.

Imagine you don't have a 'controller' and just methods on a form. You can just as easily set properties on a form in a JadeScript method (say) as you can properties on a non-GUI object.

The separation of the model and GUI greatly simplifies the application. And, having distinct boundaries around your transactions (and corresponding validations) further reduces complexity and increases (the potential for) code re-use. I've seen many an application that was just a mass of unfathomable spagetti strewn throughout the application's GUI, making maintenance a nightmare.

Add to that the greater deployment flexibility, ( business logic can be deployed in different tiers, and can be used in different applications ) and for any serious application it is definitely worthwhile.

Not sure what you mean by 'deployment': if you mean 'distribution' then that's not really an issue with Jade is it?

To me, the business rules are implemented in the model, and the application uniquely interfaces to them via the GUI. Therefore, multiple application GUIs can implement the same model in their own way.

Use in different applications: If you can identify that you're going to need the same behaviour in more than one place then I can see some use of putting that behaviour on a controller class. Is it really worth the overhead of separating things just because you might possibly need to use it somewhere else for some imaginary situation in the future?

How is there an overhead in separating the model and GUI ? If anything, this separation further encourages re-use of code rather than just chucking some operation on this form, and then on that form, and so on as is often the case.

The major "disadvantage" is that extra layer of indirection, You write more "population of the UI" or "extract data from the UI" code than you might otherwise.

More code = more testing = more to go wrong = more to change = more $.

Bullshit. Think about how much money you'd otherwise spend to reimplement an application for a new Customer.

Some things that might be easily validated inside the UI might take longer to validate with remote business logic.

Not sure what you mean by 'remote business logic'. Chances are that a validation controller object is sitting in your transient cache and there'd be no trip to the server. This is JADE we're talking about not some complicated multi-tool environment.


What do some other gurus say about layering:

Fowler on the Advantages of the Presentation/Application logic split in 'Analysis Patterns':

"Layering is a good idea in principle, but it does have some disadvantages: the extra work is required to build the layer, and a performance penalty can be incurred in using it. The important question is, are the advantages worth the costs?"

He goes on to say that "One advantage comes from the different styles of programming involved in the two layers." With Jade this isn't an issue as the whole system is built using a single tool.

He also argues that "When facade (read ActivityAgent/Controller) and presentation are combined, the base computation can only be tested via the GUI, requiring manual testing" In Jade a form is just another kind of object and can be manipulated like any other if necessary.


And our mates from Scandiwegia (Jacobson OOSE A UseCase driven Approach):

"In fact, we can build any system with just these two object types (interface and entity). However, when such a model has been developed, you will notice that there are certain behaviours that are not naturally placed, from a maintainability view, in either entity objects or interface objects; or even worse, they are spread over several objects." Okay, it's a fair cop guvna.

They say one of the dangers of using control objects:

"Beginners sometimes only use entity objects as data carriers and place all dynamic behaviour in control objects. This should, however be avoided. Using this extreme, we will end up with a function/data structure" I've seen this in a system using agents/controllers. Whereas in systems with interface and entity classes the entities seem to do a lot of validation.

Craig Larman in "Applying UML and Patterns" says:

"Motivations for a multi-tiered architecture include:
a) Isolation of application logic into separate components which can be reused in other systems.
b) Distribution of tiers on different physical computing nodes, and/or different processes. This can improve performance and increase coordination and shared information in a client-server system.
c) Allocation of developers to construct specific tiers, such as a team working solely on presentation layer. This supports specialized expertise in terms of development skills, and the ability to run parallel team ddddevelopment efforts."

As far as I can see from the above only (a) might apply in Jade and even then the classes will be so specialised the opportunity for reuse must be slight.


All the received wisdom on the subject I've seen seems to relate to toolsets and environments quite different to JADE. Perhaps we can cut a few corners and get away with it. I can see that occasionally you will benefit from employing some kind of controller class but using them unnecessarily just because it's the fashion can't be productive.

The various views in the above epistles perhaps make valid points in a broader sense, however in my personal view, and in the context of JADE, the advantages of separating the model and GUI far outweigh any perceived disadvantages.

Eric in Waitati (dark and misty and my dog wants to go for a wee)

darrell.

[ConvertFromOldNGs]

by Geoff Davies >> Tue, 11 Apr 2000 0:06:17 GMT

Surely no one disputes that the model should be separated from the view.

What Eric is proposing (playing Devil's advocate perhaps) is that in JADE there is no need for a third player - the controller.

[ConvertFromOldNGs]

by Dean Cooper >> Tue, 11 Apr 2000 3:11:21 GMT

What Eric is proposing (playing Devil's advocate perhaps) is that in JADE there is no need for a third player - the controller.

Separating entities into model and view layers is generally straightforward. The controller layer is often the most difficult to define (I personally don't like the term "controller" in this context, but I'll stick with it because that's what's being referred to in these posts). The fact that we're using JADE doesn't eliminate the need for one though. One of the main purposes of a controller layer (certainly as it's used in the Discovery Kit demo system) is to separate clearly the operations defined in the model from the transactions that group these operations into logical units of work.

For example, say you have two model operations: createPerson and createPersonVisit. In the GUI (a view), you may have a form that allows users to create people, and another form that allows users to create visits for people. These forms require the createPerson and createPersonVisit operations to be packaged in separate transactions. But say we now have the requirement to process transactions from some batch file input, or from a message queue or something (other views), and these processes want to create people and visits in the same transaction. Now we need something that packages createPerson and createPersonVisit operations in a single transaction. The controller layer is a useful place to centralise these transaction units.

You don't want to build knowledge of transactions into the model operations because this limits your ability to combine operations into new transactions. Attempting to do this can lead to this sort of code in the model:

createPerson(... params ...) : Person;
vars
needCommit : Boolean;begin

if not process.isInTransactionState then
beginTransaction;
needCommit := true;
endif;
... do stuff ...
if needCommit then
commitTransaction;
endif;
end;

Warning bells should go off if you see too much of this. Over time and as a system grows, determining exactly what constitutes a transaction can become difficult, and it can be difficult to work out where transactions start and finish. Also, an operation like this is probably making an assumption that it's going to be invoked only for persistent objects.

The packaging of transactions could be done in the views. This is preferable to doing it in the model, and many systems work this way quite successfully. However, an advantage of having a common controller layer is that you can centralise your transactions and implement a layer through which all transactions enter and exit. This provides an ideal place for common exception handling, centralising locking strategies (eg: serializing transactions), beginLoad/endLoad brackets, logging, diagnostics, etc. Often the value of this layer becomes more apparent during testing/debugging, or after a system has been deployed.

Except for prototypes or simple applications, model and view separation is always a good idea. Whether you need a controller layer as well depends more on the size/complexity of the system, and how many different views you have. For systems where there is a need to package model operations in many different types of transaction, I believe a controller layer is beneficial.
But the best thing about all of this is that people are kicking these ideas around. Good stuff!

Dean.

[ConvertFromOldNGs]

by Darrell Duniam >> Sat, 8 Apr 2000 3:18:03 GMT

Well Frankie I'm still not convinced.

At a minimum, the benefits obtained from being able to test and validate your logic independantly of the UI are major.

Imagine you don't have a 'controller' and just methods on a form. You can just as easily set properties on a form in a JadeScript method (say) as you can properties on a non-GUI object.

The separation of the model and GUI greatly simplifies the application. And, having distinct boundaries around your transactions (and corresponding validations) further reduces complexity and increases (the potential for) code re-use. I've seen many an application that was just a mass of unfathomable spagetti strewn throughout the application's GUI, making maintenance a nightmare.

Add to that the greater deployment flexibility, ( business logic can be deployed in different tiers, and can be used in different applications ) and for any serious application it is definitely worthwhile.

Not sure what you mean by 'deployment': if you mean 'distribution' then that's not really an issue with Jade is it?

To me, the business rules are implemented in the model, and the application uniquely interfaces to them via the GUI. Therefore, multiple application GUIs can implement the same model in their own way.

Use in different applications: If you can identify that you're going to need the same behaviour in more than one place then I can see some use of putting that behaviour on a controller class. Is it really worth the overhead of separating things just because you might possibly need to use it somewhere else for some imaginary situation in the future?

How is there an overhead in separating the model and GUI ? If anything, this separation further encourages re-use of code rather than just chucking some operation on this form, and then on that form, and so on as is often the case.

The major "disadvantage" is that extra layer of indirection, You write more "population of the UI" or "extract data from the UI" code than you might otherwise.

More code = more testing = more to go wrong = more to change = more $.

Bullshit. Think about how much money you'd otherwise spend to reimplement an application for a new Customer.

Some things that might be easily validated inside the UI might take longer to validate with remote business logic.

Not sure what you mean by 'remote business logic'. Chances are that a validation controller object is sitting in your transient cache and there'd be no trip to the server. This is JADE we're talking about not some complicated multi-tool environment.


What do some other gurus say about layering:

Fowler on the Advantages of the Presentation/Application logic split in 'Analysis Patterns':

"Layering is a good idea in principle, but it does have some disadvantages: the extra work is required to build the layer, and a performance penalty can be incurred in using it. The important question is, are the advantages worth the costs?"

He goes on to say that "One advantage comes from the different styles of programming involved in the two layers." With Jade this isn't an issue as the whole system is built using a single tool.

He also argues that "When facade (read ActivityAgent/Controller) and presentation are combined, the base computation can only be tested via the GUI, requiring manual testing" In Jade a form is just another kind of object and can be manipulated like any other if necessary.


And our mates from Scandiwegia (Jacobson OOSE A UseCase driven Approach):

"In fact, we can build any system with just these two object types (interface and entity). However, when such a model has been developed, you will notice that there are certain behaviours that are not naturally placed, from a maintainability view, in either entity objects or interface objects; or even worse, they are spread over several objects." Okay, it's a fair cop guvna.

They say one of the dangers of using control objects:

"Beginners sometimes only use entity objects as data carriers and place all dynamic behaviour in control objects. This should, however be avoided. Using this extreme, we will end up with a function/data structure" I've seen this in a system using agents/controllers. Whereas in systems with interface and entity classes the entities seem to do a lot of validation.

Craig Larman in "Applying UML and Patterns" says:

"Motivations for a multi-tiered architecture include:
a) Isolation of application logic into separate components which can be reused in other systems.
b) Distribution of tiers on different physical computing nodes, and/or different processes. This can improve performance and increase coordination and shared information in a client-server system.
c) Allocation of developers to construct specific tiers, such as a team working solely on presentation layer. This supports specialized expertise in terms of development skills, and the ability to run parallel team ddddevelopment efforts."

As far as I can see from the above only (a) might apply in Jade and even then the classes will be so specialised the opportunity for reuse must be slight.


All the received wisdom on the subject I've seen seems to relate to toolsets and environments quite different to JADE. Perhaps we can cut a few corners and get away with it. I can see that occasionally you will benefit from employing some kind of controller class but using them unnecessarily just because it's the fashion can't be productive.

The various views in the above epistles perhaps make valid points in a broader sense, however in my personal view, and in the context of JADE, the advantages of separating the model and GUI far outweigh any perceived disadvantages.

Eric in Waitati (dark and misty and my dog wants to go for a wee)

darrell.

[ConvertFromOldNGs]

by Kevin Alcock >> Mon, 10 Apr 2000 23:54:32 GMT

Eric,

This is my personal view on the subject. If only use the code in one place then its fine to leave it on the form, but as soon as you need that functionality somewhere else then move it out (use cut and paste NOT copy and paste). Code reuse is what your after. The cost of speculating that you might need to reuse that code later and not reusing it is greater than changing the code in the future for reuse.

<snip>

More code = more testing = more to go wrong = more to change = more $.

If you use automated tests and test scripts this is not always true. If the tests were successfull before you run then fail after you have changed some code then the error has to be with area that changed.

<snip>

What do some other gurus say about layering:

Fowler on the Advantages of the Presentation/Application logic split in 'Analysis Patterns':

"Layering is a good idea in principle, but it does have some disadvantages: the extra work is required to build the layer, and a performance penalty can be incurred in using it. The important question is, are the advantages worth the costs?"

He goes on to say that "One advantage comes from the different styles of programming involved in the two layers." With Jade this isn't an issue as the whole system is built using a single tool.

You might want to check out a book by the same author "Refactoring : Improving the Design of Existing Code".
Also "Extreme Programming Explained: Embrace Change" by Kent Beck.

<snip>

Kevin
--
kalcock@cardinal.co.nz
Cardinal Consultants
Phone: +64 3 365 2266 x 3086
Cell: +64 21 638 586