Timeline for Dependency injection and inversion of control
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 2, 2014 at 23:12 | vote | accept | Crackertastic | ||
| Jan 2, 2014 at 23:11 | comment | added | Crackertastic | Thanks again for the tips and the info. You've made me rethink what a model should be, among other things. I'm looking into the model layer with a fresh start and hopefully a new understanding. I've posted a new question pertaining to it (since I was bringing the subject off topic here). | |
| Dec 31, 2013 at 9:58 | comment | added | Elias Van Ootegem | @Crackertastic: Well, IMO, if the model layer failed at some point, it's the controller's job to then render a different view, based on the success of the overall request. If the model failed to do X, then view X shouldn't be rendered, but instead, view errorX is what needs to be presented to the end-user. A view, IMO, should receive pre-packaged/structured data and just iterate over it, and turn it into a nicely designed page | |
| Dec 30, 2013 at 22:19 | comment | added | Crackertastic | Thanks for the tips, I will do that. As for the View/Model interaction and views doing logic: it seems rudimentary that the view can't ask the model if it failed/succeeded or get some status update. If my view needs to know something that the model is going to answer, what is the real point of using the controller for that? My views do not do logic related to data processing, but they aren't dumb templates either. Basically the view is asking the model if it succeeded so it knows to display an error message or success message. Perhaps we have different philosophies on how to utilize MVC. | |
| Dec 30, 2013 at 22:03 | comment | added | Elias Van Ootegem | frameworks deal with this sort of stuff. Symfony2 has a very elaborate and powerful Form component, it might be worth a look. (tip: think of symfony's forms as services, linked to doctrine entities) | |
| Dec 30, 2013 at 22:02 | comment | added | Elias Van Ootegem | @Crackertastic: I think I'd need to see that code, but from the looks of things, I'd say you're actually mixing what Form-builders should do with the view's job. A view should contain no logic whatsoever. It consists of markup, some loops and the occasional if and else, but other than that, it does nothing but render the result. Checking a form/input's validity is done by the controller + model layer. I'd suggest you look at some of my other aswers on this site (I'm mainly active on the PHP tag anyway) and perhaps post a separate question focussing on your models. Also check how existing | |
| Dec 30, 2013 at 19:16 | comment | added | Crackertastic | Okay, I think is see what you mean with DB models. With models I didn't necessarily consider strict SRP, but instead kept responsibilities as low as possible. For example (non-DB related) in one project I had a model that I used to build an email. The model would accept user input, sanitize it, error check, and then store status/error info and build/send the email message if there were no errors. The view would query the model for indications that an error occurred (or succeeded) so something would be created on screen for the user. Do you think this is a bad approach in MVC context? | |
| Dec 30, 2013 at 17:15 | comment | added | Elias Van Ootegem |
@Crackertastic: On your IoC container thing: yup, it's just a factory + registry wrapper. It still requires you to IoC::set all dependencies you might need, which will then simply add those instances to an aptly named $registry property... Because it's all statics, the methods and properties essentially work in much the same way as globals do, only with the added noise (and overhead!) of object orientation (check google: static methods actually take longer to call than regular globals do, because of PHP having to create the self:: reference + specific scope
|
|
| Dec 30, 2013 at 16:58 | comment | added | Elias Van Ootegem |
@Crackertastic: In an MVC context, the Model bit should be treated as a layer, not an object. In my projects, models are pure data carriers, that are passed on via a service (that is accessed by the Controller), who then passes them on to a data mapper, which maps the model onto a database. These mappers can also contain queries that simply return Models, too. If you swap those out for mock objects, or return mock Models, you're home free... Injecting DB connections into data carriers is, IMO, a violation of the SRP (Single Responsibility Principle).
|
|
| Dec 30, 2013 at 16:37 | comment | added | Crackertastic | Thank you for the (very) thorough answer. You've managed to shed a lot of light on the design principals I need to focus on. From your explanation my IoC container isn't really that, but more of a factory with a registry component, yes? In a practical example, let's say I am using the MVC pattern and I have 20 different models with 15 of them needing DB access. My goal would be to have a universal way of injecting the DB into all of those models but at the same time have the ability to swap out a DB connection for a mock or alternate DB without changing them all. Any suggestions for that?? | |
| Dec 30, 2013 at 12:40 | history | answered | Elias Van Ootegem | CC BY-SA 3.0 |