I have a similar situation to Beck here, I believe. Previously, Steven Webster had said that he'd 'err towards Scenario 2'.

Now, the difference for me is that we have one large project that will actually multi-task as different apps. That is, we want to share code for two very similar apps that will only differ as to service locations and that kind of thing (different servers, etc.). At runtime, we're loading a config file to determine application behaviors, (different artwork, etc.).

According to Beck's chart, I'd have:

+ Common Code Base
  •    business
  •    commands
  •    control
  •    model
  •    view
  •    vo
   + Client Code 1
  •    business
  •    commands
  •    control
  •    model
  •    view
  •    vo
   + Client Code 2
  •    business
  •    commands
  •    control
  •    model
  •    view
  •    vo

I'm guessing the FrontController determines which app we're running as and sets the app type in our model?

Also, in this case there may be a Main Controller at the top and sub-Controllers down below? What is the best practice to deal with this in Cairgorm?

And if anyone has better suggestions, I'm wide open to them!

Thanks,

Scott


On 2/1/06, Beck Novaes < [EMAIL PROTECTED]> wrote:
What do you think is the best way to structure folders in a big
Cairngorm Application?

I'll give you two scenarios.


SCENARIO 1
==========

In this Scenario the application is defined by the Cairngorm structure
and I use Use-Case-subfolders* in the commands, views and VOs for each Use Case.

+ business

   UseCase1Service.as
   UseCase2Service.as

+ commands

   + useCase1*

      UseCase1Command1.as
      UseCase1Command2.as

   + useCase2*

      UseCase2Command1.as
      UseCase2Command2.as

+ control

   UseCase1Control.as
   UseCase2Control.as

+ model

   UseCase1ModelLocator.as
   UseCase2ModelLocator.as

+ view

   + useCase1*

      UseCase1View1.mxml
      UseCase1View2.mxml

   + useCase2*

      UseCase2View1.mxml
      useCase2View2.mxml

+ vo

   + useCase1*

      UseCase1VO1.as
      UseCase1VO2.as

   + useCase2*

      useCase1VO1.as
      UseCase1VO2.as


In the structure above, I use Use-Case-subfolders* for commands, view and vo.
It's necessary Use-Case-subfolders only for commands, views and VOs, because
I'll probably have only one service/control/model by Use Case.



SCENARIO 2
==========

In this scenario the application is defined by the Use Case structure
and I use Cairngorm-subfolders* for each Use Case

+ useCase1

   + business*

      UseCase1Service.as

   + commands*

      UseCase1Command1.as
      UseCase1Command2.as

   +control*

      UseCase1Control.as

   + model*

      UseCase1ModelLocator.as

   + view*

      UseCase1View1.as
      UseCase1View2.as

   + vo*

      UseCase1VO1.as
      UseCase1VO2.as

+ useCase2

   + business*

      UseCase2Service.as

   + commands*

      UseCase2Command1.as
      UseCase2Command2.as

   + control*

      UseCase2Control.as

   + model*

      UseCase2ModelLocator.as

   + view*

      UseCase2View1.as
      UseCase2View2.as

   + vo*

      UseCase2VO1.as
      UseCase2VO2.as


I the structure above, I use Cairngorm-subfolders* for each Use Case.



CONSIDERATIONS
==============


SCENARIO 1

In my opinion this Scenario looks more coherent, but there is one
inconvenience.
Generally I'll be working with only one Use Case. But imagine you are editing
"useCase1VO1.as" and now you need to open "UseCase1Command1.as". Do you know
What I mean? If you have many Use Cases it can be laborious because of the
scroll in your structure. If you use Eclipse you can figure out this by
defining Working Sets.


SCENARIO 2

At a first look this structure seems simpler. But I don't like it because
one Cairngorm Structure by Use Case makes me fell like If I have one
Cairngorm by Use Case. Since Cairngorm is for complex applications
I don't think it should be entirely structured for a simple Use Case.



What do you think? Do you know another way to organize big Cairngorm
Applications?



Thanks
Beck Novaes
[EMAIL PROTECTED]


--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS






--

: : ) Scott

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com




SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS




Reply via email to