Command confusion

[creynders]

I'm a bit confused about the responsibilities (and use) of commands. When I look at the provided examples I notice there are examples where all remote access is done through commands ( for instance there are commands for all CRUD operations in the Bookstore example)
But then in another example (IndexCards) all remote access is done through the proxies.
I'm not sure which approach I need to take.
I'm working on an application with around 20 tables and approximately the same amount of views. If I cut up all CRUD operations to separate commands this'll give me 60+ commands. That seems WAY overkill. But on the other hand if I go for the proxy-approach, I'll only have 3 (Startup, ModelPrep and ViewPrep) and suddenly commands seem completely useless to me.
So, when should I decide to put something into a command and when can I leave it to the proxy?
(I read the chapter on commands in the "best practices" document, but I must confess that I'm not familiar with most of the expressions like 'domain logic' etc. Looking them up at Wikipedia didn't make me any wiser, on the contrary)

[puremvc]

The Best Practices guide should be your final arbiter in questions like this.
The Bookstore I believe is being rewritten to follow the best practice of using Proxies. It is a user contributed demo, originally written from the perspective of someone coming from Cairngorm.I allowed it but later decided its to confusing to keep 'Cairngorm-friendly' demos around, as you've found so the few that were like that have been or are in the process of being refactored to use Proxies.

If you look at the trunk of the Bookstore app in the repo you may find these changes already made an I just haven't bagged and tagged it yet. I'm on a cellphone at the moment or I'd verify this.

Sorry for the confusion. Again, read the Best Practices doc, it'll make things clearer.

-=Cliff>

[puremvc]

Hi again,

I've made it to my desk now and I find that it was me that had been slack on the Bookstore demo after all. David checked in his updates some time ago, somehow it I let updating the archive, tag and source view for it slip through the cracks.

I've tagged the project now, and the archive and view source are updated to reflect best practices in handling services.

I'm terribly sorry for any confusion this may have caused, and thanks for bringing it to my attention.

Thanks,
-=Cliff>

[creynders]

Thanks for the swift reply and action. Cliff, you really are one of the major advantages of this framework
I hadn't realized that some of the tutorials didn't follow best practices entirely (are there others?)
Just one more thing: in the best practices document you write:

Commands house the business logic of our application

(p. 18) and a few lines further:

The Model maintains its integrity through the use of Proxies, which house domain logic and [...]

When I look up "business logic" and "domain logic" at wikipedia both phrases lead me to the same article. Could you explain the difference to me? Or point me to a site which does?
I'm sorry for such noobish questions!

[puremvc]

On the difference between Business Logic and Domain Logic, if you happen to have a copy of Floyd Marinescu's excellent 'EJB Design Patterns' layimg around, flip to page 129 for a very good treatment of the problem from an EJB server side developer's perspective.

Essentially it boils down to business logic being workflow activiy, such as coordinating  updates to multiple, possibly unrelated domain objects in order to fulfill a use case. Domain logic acts on the domain model itself.

From an EJB perspective, services are seperated from domain logic and are relegated to business logic.

However in a stateful client, there are pressures that make it more reasonable to move service interaction into the model region.

1. The Proxy classes are often something we want to reuse across clients. Being able to package the model classes separately and placing the logic for accessing the domain services makes sense.

2. Explosion of classes. Systems that use commands for service interaction tend to have large numbers of commands, each of which do little more than take a result and hang it on the model.These commands have to be registered, so for the model to maintain integrity requires model code, command code and controller initialization code. Again not easy to pick up and drop into a new client app.

So on the client, there is still a division of labor between business and domain logic, even if the some of what an EJB developer would call business logic is moved into our domain logic (i.e. services).

Client-side business logic is used to coordinate complex activities such as prreparing the Model and View at startup.

Hope this helps,
-=Cliff>   

[creynders]

Thanks a bundle for the response, it's much more clear now!