There is one practical argument for having the business logic in the model - it is the necessity of using it from command line/cron job tools. I have not yet heard a similar argument from the other side - that is for having the logic in the controller.
--ZbyszekOn 8/21/06, [EMAIL PROTECTED]
If I reformulate my statement as follow:There is one practical argument not to have the business logic in the controller - it is ...Can we agree?The result I would like to get from this conversation is that I don't see some point of time controllers with business logic in them at CPAN.
--ZbyszekOn
Mark Blythe wrote:
If the controller truly never sees DBIC stuff, does that mean that
your model logic never returns DBIC objects? For instance, let's say
you have a logic method called findBestFit() that's supposed to return
shoes that fit a given person and activity the best. Would it
Mark Blythe wrote:
I think the main bone of contention here is that Len is referring to his
persistence layer as the model, whereas I consider it to just be a
persistence
layer - stuff like Model::DBIC::Schema is really only there for simple apps
where what you're modeling *is* the database.
Matt S Trout [EMAIL PROTECTED]
08/21/2006 :
I tend to return the DBIC objects
but make sure the controller only ever
interacts with *semantic* methods
rather than the DBIC-specific
find/search/etc. so I could swap
it out for such an extra layer if I ever need to.
I think we just agreed on
I am glad to see that the 'business logic in the model' side seem now to prevail in the Catalyst world. It was not so in the past - as this thread documents:
http://lists.rawmode.org/pipermail/catalyst/2005-August/thread.html#1148 There is also a wiki page on this
Brian Kirkbride wrote:
At this point, if I want code reuse I have two reasonable choices:
A) Create business logic modules, ie. MyApp::Logic::CreateTrial, etc
B) Write my own business logic methods in MyApp::Schema::Trial-create(...)
Either is valid and from what I gather Java developers
On 8/19/06, Matt S Trout [EMAIL PROTECTED] wrote:
I think the main bone of contention here is that Len is referring to hispersistence layer as the model, whereas I consider it to just be a persistencelayer - stuff like Model::DBIC::Schema is really only there for simple apps
where what you're
A. Pagaltzis wrote:
* Matt S Trout [EMAIL PROTECTED] [2006-08-19 16:55]:
If you're modeling a domain, then your Model::* stuff should be
the model of the domain, and whether or not said model happens
to use DBIC stuff as its persistence store should be merely an
implementation detail that the
McBrearty [EMAIL PROTECTED]
To: The elegant MVC web framework catalyst@lists.rawmode.org
Sent: Friday, August 18, 2006 5:47:36 PM
Subject: [Catalyst] ways to do stuff and why
if you need to add some block of functionality to your project, how
many ways are there to do it?
1. Add a model. For any data
John Napiorkowski wrote:
You may want to review the thread, Plugins vs. Base Controllers to see what
some of the lead architects have to say on the issue at least regarding 2/3
and 4. I think choosing between 2/3 is really a matter of what can be reused
usefully and what is overkill
[EMAIL PROTECTED] wrote:
Matt S Trout [EMAIL PROTECTED] on 08/18/2006 12:33 PM:
Ek, not at all. The model should encapsulate *all* business logic
and
similar - it should be a model of the domain with which the app
interacts. The
Controller should be as thin a layer as possible
Brian Kirkbride wrote:
[EMAIL PROTECTED] wrote:
Matt S Trout [EMAIL PROTECTED] on 08/18/2006 12:33 PM:
Ek, not at all. The model should encapsulate *all* business logic
and
similar - it should be a model of the domain with which the app
interacts. The
Controller should be as
On Friday 18 August 2006 10:57, Brian Kirkbride wrote:
This is what I had thought initially, but I have come to see the benefit of
doing it the way Matt describes.
This is the right way of doing it. Another reason for not throwing business
logic into controller is, that sometimes you want to
Brian Kirkbride [EMAIL PROTECTED]
@ 08/18/2006 01:57 PM:
[EMAIL PROTECTED] wrote:
Matt S Trout [EMAIL PROTECTED]
on 08/18/2006 12:33 PM:
[ Matt's Way ]
[ Len's way %]
This is what I had thought initially,
but I have come to see the benefit of
doing it the way Matt describes.
I
[EMAIL PROTECTED] wrote:
Brian Kirkbride [EMAIL PROTECTED] @ 08/18/2006 01:57 PM:
At this point, if I want code reuse I have two reasonable choices:
A) Create business logic modules, ie. MyApp::Logic::CreateTrial, etc
B) Write my own business logic methods in
following this with interest. I'm a beginner at this stuff, but the
way I am seeing the problem goes something like this:
1. devise a schema for the data that needs storing that is as robust
and future proof as I can make it.
2. figure out how the front end logic wants to see that data to make
17 matches
Mail list logo
