oh, I&#39;ve also started playing with Bread::Board and its looking like my &quot;model&quot; layer consisting of the DBIC Schema and all my &quot;Sets&quot; will be pulled together into a single Bread::Board container.<div>
<br></div><div>J<br><br><div class="gmail_quote">On Mon, Jan 2, 2012 at 1:36 PM, Jason Galea <span dir="ltr">&lt;<a href="mailto:lists@eightdegrees.com.au">lists@eightdegrees.com.au</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Bill,<div><br></div><div><div class="gmail_quote"><div class="im">On Mon, Jan 2, 2012 at 11:41 AM, Bill Moseley <span dir="ltr">&lt;<a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>So, I&#39;m looking at adding a separate model layer(s) (&quot;pattern #3&quot; in link above), as is commonly suggested.  My plan is to have one &quot;distribution&quot; 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>

</blockquote><div><br></div></div><div>I think I&#39;ve added another layer but I&#39;m not sure where you draw the line.. I have a model layer over DBIC pulling together related result classes under a single model class. Then the app? layer uses the model layer to get things done. So I&#39;d probably have one &quot;distribution&quot; that is our DBIC wrapped in a model layer layer and use that in a number of apps.. 8) Each app can then be used as the single model in a Catalyst app or script or whatever.. (I think I need more names for the parts..)</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>Anyone here doing something like this?   As I look into this I&#39;m coming up with quite a few questions, of course.</div></blockquote><div><br></div></div><div><div>I&#39;ve been trying learn the steps to this little dance for a while now and still haven&#39;t put anything into production, but for what it&#39;s worth, here are some of the things I&#39;ve implemented in my most recent code..</div>

<div><br></div><div>I have &quot;Sets&quot; in lu of ResultSets and &quot;Models&quot; for Results. Although in most instances a Model will actually cover the usage of multiple Results. Each Set gets the dbic schema object and knows it&#39;s resultset name. Each model has a data attribute which contains a dbic row object and &quot;handles&quot; any methods I don&#39;t need to override via the Moose &quot;handles&quot; attribute attribute!?</div>

<div><br></div><div>Set-&gt;create($hash) creates the dbic object and stuffs it into a model class and returns that.</div><div>Each result class that has a model class overrides it&#39;s inflate_result method which again stuffs the dbic row object into the model object so searches on the related dbic resultsets return my model objects.</div>

<div><br></div><div>Each model class has a validation class based on.. Validation::Class and create &amp; update run their input through that. If there are errors I stuff the errors into a very basic exception object and return that. This way I can return the same exception object no matter where the error comes from, eg a dbic exception..</div>

<div><br></div><div>So my app can use the Login set to create a login model which has methods to set/get email &amp; username, check the password, set a temporary password, add to roles, and get roles by name. Beneath that is 3 or 4 DBIC result classes which the model class works with via custom methods or delegation.</div>

<div><br></div><div>ok, sorry.. I&#39;ll stop there. This has turned into a brain dump and clarity has suffered badly.. I hope you got something for your trouble..</div><div><br></div><div>cheers,</div><div><br></div><div>

J</div><div><br></div><div></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><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&#39;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-&gt;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&#39;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><span><font color="#888888"><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>
</font></span><br></div>_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk" target="_blank">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" target="_blank">http://dev.catalyst.perl.org/</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>