oh, I've also started playing with Bread::Board and its looking like my "model" layer consisting of the DBIC Schema and all my "Sets" will be pulled together into a single Bread::Board container.
J On Mon, Jan 2, 2012 at 1:36 PM, Jason Galea <li...@eightdegrees.com.au>wrote: > Hi Bill, > > On Mon, Jan 2, 2012 at 11:41 AM, Bill Moseley <mose...@hank.org> wrote: >> >> 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. >> > > I think I've added another layer but I'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'd probably have one "distribution" 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..) > > >> >> Anyone here doing something like this? As I look into this I'm coming >> up with quite a few questions, of course. >> > > I've been trying learn the steps to this little dance for a while now and > still haven't put anything into production, but for what it's worth, here > are some of the things I've implemented in my most recent code.. > > I have "Sets" in lu of ResultSets and "Models" 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's resultset name. Each > model has a data attribute which contains a dbic row object and "handles" > any methods I don't need to override via the Moose "handles" attribute > attribute!? > > Set->create($hash) creates the dbic object and stuffs it into a model > class and returns that. > Each result class that has a model class overrides it'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. > > Each model class has a validation class based on.. Validation::Class and > create & 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.. > > So my app can use the Login set to create a login model which has methods > to set/get email & 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. > > ok, sorry.. I'll stop there. This has turned into a brain dump and clarity > has suffered badly.. I hope you got something for your trouble.. > > cheers, > > J > > > > >> >> 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. >> >> 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? >> >> 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. >> >> Thanks for any feedback you can provide, >> >> -- >> Bill Moseley >> mose...@hank.org >> >> _______________________________________________ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: >> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ >> >> >
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/