DP Framework

[see4th]

Mike / Jeff,

Love Breaking Out... awesome read! One of the few that include a
sample at that uses design patterns.

I like your clean Command-centric design but noticed the sample app
was missing the typical Controller.

- Is your 'View code-behind' somewhat of a pseudo controller for each
View?
- Would the dp framework be suitable for a scaling enterprise app with
4 or 5 developers?
- Are your code-behinds the solution for the bloating Controller
issue?

I like your advise in the book on frameworks. As such, I'm leaning
towards following good practices and trusting my programmers will do
the same so that we're not 'locked' into a specific framework - since
they all seem to have distinct weakness. What are your thoughts.

Thanks for your input.

Jeff

[Michael Labriola]

Jeff,

Glad you liked the book. So, our 'framework' is really just a couple
of design patterns. In fact, if you simply have our commands implement
IResponder instead of extend the commandAdapter and have the Service
layer just manually add the responder to the asyncToken, you really
don't need any classes from the framework at all. (not counting the
few things we wrote for handling SQL commands, but those are easily
replicable as well)

Basically, in a lot of frameworks the controller is reponsible for
managing the call between the view and the command. We understand this
but at some point you are doing just as much work to populate an event
object or some other type of thing and send it on its way as you are
to just call the command. While this way has more coupling, it also
means it is clear where commands are called from and when a command is
no longer needed or used the linker can optimize it out of the final
file. There are advantages and disadvantages, but we like it.

As far as an enterprise app, the term gets rather overused, so it
depends on what you mean, however, there is nothing inherently
limiting about this design. As you grow it scales linearly, the
biggest challenge is just maintaining order to your views and commands
so that they still make sense. Basically, this is about the lightest
weight thing we could conceive of that helped you to organize and
structure code without imposing a lot in the way of rules.

At the end of the day, you need to be comfortable with any route you
choose, but I am only in favor of order that does not come at the
expense of innovation.

My 2 cents.

Cheers,
Mike

[see4th]

Mike,

Thanks for the reply.

Can you elaborate on, "There are advantages and disadvantages, but we
like it."

I really like what I see in the TimeTracker because it's extremely
intuitive, but I'm not clear at this point what no-no's might come
along with the clarity of design?

Thanks,

Jeff

[Michael Labriola]

I mean that some people feel having commands called directly is a
problem because you are effectively coupling that command to the view.
In an environment where you dispatch and even and have a controller
call the command, these are decoupled and you could theoretically vary
which command is called when an evant happens without ever touching
the view. This is valid and if this is likely to be a situation that
you encouter then you are better off with that type of design.

In my experience the level of abstraction that the command provides
you through the service factory is more than sufficient, so I don't
worry about it.

In either case, there needs to be some coupling between pieces. The
arguments are simply where that coupling should exist.

Personally, I like the metaphor used in the book for the most part.
There are some places where too much code is incorporated into the
view either because it was more convenient to explain or just because
it should have been refactored. So, I would say if you follow the
general strategy but keep the code in the views and code behind
directly related to the views (for instance if there is code that
needs to create a bunch of objects for a database or drag and drop
operation, move that into some utility class) then you are likely
good.

Mike

> > > Jeff- Hide quoted text -
>
> - Show quoted text -

[see4th]

Thanks, Mike. That helps a bunch.
Jeff

BTW, Enterprise for us = 8 standalone Flex/AIR apps rolled up into one
giant AIR application, that will serve as a central manager. Most of
the apps share much of the same data, and user gestures in one app
often dictates the state of the other apps.