Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Architecture 101 Questions  (Read 21783 times)
pedr
Port to AS2
Full Member
*
Posts: 27


View Profile Email
« on: September 23, 2007, 05:31:09 »

Hi,

Having read through the best practices (and got quite excited), I downloaded the architecture 101 demo, but I am a little confused.

1. How come the Mediators are directly accessing the Proxies. Shouldn't they use a command?

2. Why does DeleteUserCommand send a notification for USER_DELETED. Surely it would make more sense for the proxy to send it when a user is deleted?

I'm really impressed by your emphasis on documentation and demos. So many other frameworks are crippled by a lack of learning material. The best practices is really well written and very helpful.

Thanks
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: September 23, 2007, 08:47:57 »

Hi Pedr,

1) It's an accepted collaboration pattern for a Mediator to retrieve a Proxy and access it's data, and in fact this is the usual way that the Model data makes it into the View Components in a PureMVC app. If there is some complicated transformation of the Model data or it is being assembled from multiple Proxies, then we would usually call that 'Business Logic' and push it into a Command.

2) In the Architecture 101 demo, the DeleteUserCommand must perform several operations before the user can be considered deleted. It must remove the RoleProxy reference to the user and the UserProxy reference. Once both operations are completed, then we can send the Notification, and that's why it's done from a Command and not a Proxy.

Now on this second point, it could be argued (strongly in fact) that the operations being executed by the Command are 'Domain Logic' and therefore belong in a Proxy, as you suggest, and not in a Command.

In fact for funzies, you could refactor the app to do this, drop the Command and do it all inside the UserProxy. This means that the UserProxy must retrieve a reference to the RoleProxy and do the removal of the Role reference before sending the Notification. You'd need to invoke the method from the Mediator that received the original DELETE event from the user.

In the Architecture 101 course, this demo comes from a Unit where we eventually refactor the entire Model into its own package, so that it can be used across multiple applications. An administration app, (the demo) and an IntranetShell app, where the user can log in and see stuff that is related to their Role.

In that set of applications, we only do user deletion in the maintenance application, and nowhere else. So it made sense to handle this Domain Logic with a Command rather than bog down the Model tier with code that won't be used elsewhere.

When Mediator to Proxy communications are simple, then there is rarely a need for a Command to be involved. However if there were multiple UI gestures that might lead to deletion, and at some point you decide to insert a 'Are you sure?' popup into all use cases leading to deletion, then you might be glad that you implemented it as a Command that responds to a Notification from the View. Otherwise you'd find yourself visiting each Mediator and adding the popup logic (or, more likely refactoring to a Command).

Both of your questions center around the question: 'What is Business Logic and what is Domain Logic, and where do they go'? Keep in mind we generally want Business Logic in Commands and Domain Logic in Proxies, but there are exceptions to every rule.

-=Cliff>
Logged
pedr
Port to AS2
Full Member
*
Posts: 27


View Profile Email
« Reply #2 on: September 24, 2007, 04:44:49 »

Hi Cliff,

Thanks for the comprehensive reply. Really loving this framework. I love the fact that it's not trying to be all things to all men and is so much stronger because of it. By far the cleanest and most solid framework I've looked at. Thanks for the Arch101 add. Will start on it as soon as I can. Was really looking forward to using PureMVC on a new project, but my client has decided they want it in AS2. Actually considering trying to build an AS2 version as I'm already feeling handicapped without it.

Thanks,

Pedr
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: September 24, 2007, 08:51:58 »

Pedr,

The idea of trying to backward-port PureMVC to AS2 has crossed my mind more than once. The primary reason is that I think it would be perfect for doing Flash games for phones and other portable devices since it is so lightweight.

But then I keep thinking surely Adobe will get AS3 in FlashLite soon. And we get further and further away from the days of AS2, and it gets harder to remember what fatal flaws and gotcha's I might run into if I tried.

Since you are being immersed in an AS2 project at the moment, any thoughts you might have on the subject of a potential port would be extremely useful.

-=Cliff>
Logged
pedr
Port to AS2
Full Member
*
Posts: 27


View Profile Email
« Reply #4 on: September 24, 2007, 11:09:33 »

Hi,

Having had a good look at the code, I can see one big problem with a port - the passing of command classes into the Controller for later instantiation. This also effects the Facade and MacroCommand classes. As2 doesn't allow the use of a Class datatype so how to create the commands on call? The only alternative seems to me to hard-code them into the Command class for each project and any MacroCommands or use a factory, but that is ugly.

What do you think?

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: September 24, 2007, 06:38:45 »

True that.

I remember Cairngorm used to instantiate all the Commands up front and cache them in the same way we typically eagerly create Proxies and cache them with the Model. It was only later that they went to lazy creation.

We could do that here. In the initializeController method, we could pass in not class names but instances to be cached.

I understand the problem with MacroCommands, what specifically about the Facade would be affected?

-=Cliff>
Logged
pedr
Port to AS2
Full Member
*
Posts: 27


View Profile Email
« Reply #6 on: September 25, 2007, 01:41:19 »

Hi,

Re. The Facade, only that it was having a Class datatype passed through it via the registerCommand()

Definately makes sense to pass instances in which would solve that problem.

Actually went through all the code last night, and it looks like a really easy job to port excepting the problem with the commands. Only other problem I can see is the use of constants, but could just switch them to private vars with only a getter. Oh and changing void to Void :)

Just out of interest, why don't you cache the commands in the controller once they are created?
Logged
immerzeel
Courseware Beta
Jr. Member
***
Posts: 14


View Profile Email
« Reply #7 on: September 25, 2007, 02:17:15 »

I would love to see an AS2 port.

It will make it all-round applicable, as AS2 is still the dominant version, at least in project I do.

Cheers,

Pascal
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: September 25, 2007, 04:41:16 »

Pedr,

Commands should be stateless, and caching them would encourage giving them state, a pitfall that often caused problems in Cairngorm back in the day.

Pascal,
I suppose I've just been living on the bleeding edge with MacAdobe products for too long. It really comes as a surprise to hear that folks are still clammoring for AS2 apps. I'm sure the handheld industry will for a while. Hmmm... I'm really starting to think about this now...

-=Cliff>
« Last Edit: September 25, 2007, 05:59:52 by puremvc » Logged
pedr
Port to AS2
Full Member
*
Posts: 27


View Profile Email
« Reply #9 on: September 26, 2007, 01:08:55 »

Hi Cliff,

Been having a think about lazy instantiation vs passing in instances of commands in an AS2 version.

How about if instead of passing in instances of commands, we passed in instances of command factories. Each factory would extend an Abstractfactory class, filling its one empty public command 'createCommand()' with code creating a concrete command and calling execute() on it. When passed in, the factory could be mapped to a notification, just like commands are at present. The controller could then call createCommand() on the relevant factory whenever it needed to instantiate a command, allowing lazy instantiation to be retained.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #10 on: September 26, 2007, 06:35:57 »

Its the right pattern to use and I believe it would work just fine.My only reservations are that it increases complexity and diverges a bit much  from the existing framework.

My feeling is that the goals of minimizing complexity and of keeping ports as similar as possible  tug me away from what would otherwise be a perfectly reasonable solution.

I'm thinking that eager creation and registration of long living commands with the admonition to keep them stateless is probably a better compromise. Cairngorm was this way at one time and it didn't get in the way of 'doing things right' if you were aware that Commands should be stateless.
-=Cliff>
Logged
immerzeel
Courseware Beta
Jr. Member
***
Posts: 14


View Profile Email
« Reply #11 on: September 26, 2007, 05:19:08 »

Exactly.

Developers know the pattern rules. Tightening it down would only add to the complexity of the framework.

Are you still deciding or certain about porting to AS2?

Cheers,

Pascal
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #12 on: September 26, 2007, 09:03:59 »

Actually, I'm pretty certain, its just when.I might have some time during MAX this weekend and next week.if I'm lucky.I'll keep you posted.

-=Cliff>

Logged
Pages: [1]
Print