Our apps tend to use the "pattern #2" as simply described at: <a href="http://www.perlmonks.org/?node_id=915657">Catalyst Models Definitive Guide</a> -- that is, our model is DBIC with business logic added to the resultset classes. But, much business logic is finding its way into the controllers. The apps also tend to grow into monolithic beasts. And we have the need to use the "app" for multiple uses -- for example we currently need to add a custom API for a specific purpose that needs to live in its own Catalyst app.<div>
<br></div><div>So, I'm looking at adding a separate model layer(s) ("pattern #3" in link above), as is commonly suggested. My plan is to have one "distribution" that is our DBIC layer and then use that in a number of separate model layers (split out by functionality). The goal is to allow separate teams to work on different parts of the app, have separate unit tests, and separate release schedules. And to thin out the controllers. Much more manageable and scalable.</div>
<div><br></div><div>Anyone here doing something like this? As I look into this I'm coming up with quite a few questions, of course.</div><div><br></div><div>This is more of a Perl question than a Catalyst one, but one question I have is about data validation. Catalyst provides a nice defined request structure so, for example, I have input data validation managed very consistently (e.g. validation classes can be mapped to Catalyst actions automatically and likewise validation errors can be added to the response in a common way). That makes the controller code simple since when the controller runs it knows if the data it has received is valid or not and the controller does not worry about gathering up error messages.</div>
<div><br></div><div>So, I'm wondering how best to do that if I provide a separate model layer that includes data validation. For example, say I have a model for user management which includes a method for creating new users. If I have a model method $users->add_user( \%user_data ) I would tend to have it return the new user object or throw an exception on failure. What probably makes sense is using exception objects and have Catalyst catch those to render the error in an appropriate way. Is this an approach you are using? Any other tips on structuring the model layer that works well with both Catalyst and non-Catalyst applications?</div>
<div><br></div><div>Looking back, I think my question isn't that much about data validation as is about providing a framework for model creation such that a consistent API is provided -- making it easy to hook it into Catalyst for things like rendering errors in a consistent way.</div>
<div><br></div><div>Thanks for any feedback you can provide,</div><div><br></div><div><div><div><div><div><div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>
</div></div></div></div></div></div>