jfredett
commented
12 years ago Part of the goal is to host Percy on Heroku, so that we'll have access to a variety of backend tools, I'm currently talking with a guy from heroku who's working on RBX support there, hopefully it will be ready soon.
We can therefore put off deciding on ORM frameworks roughly indefinitely -- it's pretty easy to pick up an ORM for various backends, and when we need it, we'll set it up.
As far as MVC. There are two points I want to address, one is more important.
We don't really need a view layer. The model and the controller can share this action. (emphasis mine)
That's an antipattern, right there. If you ever find yourself assigning more than one responsibility to an object, you're going down towards a violation of the Single Responsibility Principle. That's bad news.
As far as MVC, I'd say that Percy is actually pretty MVC to start, though it doesn't look like Rails MVC.
Indeed, Percy loads a series of plugins, and acts as a router for them, dispatching commands as specified in the Controller (Plugin) classes, these classes ideally delegate to pure ruby objects (see, for instance, the clock or logger plugins), these objects are the Models, containing all of the domain logic. The plugins ideally just act as interfaces to communicate with those objects.
Remember that MVC is a pattern, not a mantra. The names change, but the important lesson it teaches is separation of concerns. In our case, that separation is bot/irc layer, plugin layer, and PORC (plain-old-ruby-code) layer.
Rails, honestly, has made many pretty unfortunate decisions wrt MVC, in particular, AR Backed models are an overengineering -- most models could be better modelled as Pure Ruby code interacting with many, simpler "Active Record" objects (I quote to emphasize that I mean the AR pattern, which predates the AR ORM framework). Rather, Rails encourages a lot of bad behavior wrt throwing things into databases, shoving lots of filters/logic into controllers, and haranguing logic into views.
If there is one thing I would definitely like to avoid w/ Percy, it's following the Rails framework too closely!
That said, there are some good ideas in here -- in particular, the "rake routes" functionality would be really nice, but I think that it will be easier in light of a new IRC framework entirely. Alternately, it's possible to build a mock Cinch module which takes the place of the Cinch Plugin module and turns the #match macro into a puts statement which achieves the same functionality. The other good idea is that MVC as a pattern should be embraced (and indeed I think it is), but I think that the methodology in which we embrace it is novel for someone who's primary experience with it is rails.
I envision adding an mvc structure to this project.
We would have control and can separate ourselves both from the Cinch layer and our LPMClient layer. We would just make one plugin that catches all messages and hands them to the router then the renderer hands the output back to the plugin. It would be a great learning experience because we will probably model it heavily off of rails which I assume is something most of us are interested in.