I asked around on various IRC channels but was unable to get an answer with a definitive explanation behind it. Should errors (pertaining to the model, such as transaction failures) be handled in the model, or in the controller?
Thanks in advance for any help.
EDIT
Well, the confusing thing is that my code (in the model) looks something like this already:
try
{
// Connect to MongoDB
// Fetch a record
}
catch (MongoConnectionException $e)
{
// Handle this error
}
catch (MongoException $e)
{
// Handle this error
}
So, should I return exceptions based on the exceptions MongoDB returns? Or should I directly allow these exceptions to bubble up to the controller?
Thanks!
The correct answer is "Both", but mostly in the Model.
The appropriate thing for your controller to do is simply catch some exception that the model throws, and handle outputting a nice "whups" message. Depending on how you're structuring your models, it might be appropriate for the controller to do some logging.
Anything other than catching the exception, maybe writing to a log (if your model infrastructure doesn't do it), and displaying a pretty error, does not belong in your controller.
Errors such as a transaction failure - and what to do in such cases - are business logic issues. Thus, they should be handled in the model and appropriate notifications passed back up to the controller.
Fat model, skinny controller.
In most cases, you should throw or pass exceptions to the caller/receiver AKA Controller or BLL.
It's controller's job to process actions not model
It's view's job to display a message box(or whatever) not model
You can't HANDLE exceptions in model, for real... you can only log or throw them.
Scott Guthrie for ASP.NET C# suggests using the Controller as the exception handler. He also, suggests setting up helper objects and handlers for the project. This in turn allows you to continue your development as normal.
Note, however with PHP MVC is still in its earliest stages and implementation so, this may not be perfect.
I do think that once you have decided how to handle the solution that you still with it and follow that pattern once you have made the decision.
The ideas behind MVC frameworks are quite simple and extremely flexible. The idea is that you have a single controller (such as index.php) that controls the launch of applications within the framework based on arguments in the request. This usually includes, at a minimum, an argument defining which model to invoke, an event, and the usual GET arguments. From there the controller validates the request (authentication, valid model, request sanitization, etc.) and runs the requested event.
At present the are only really two true frameworks...and this could be a problem for coding, support and future releases. Though, there are alot of frameworks that extend themselves to support MVC.
By Earliest stages, I mean to say and suggest that the current frameworks, solutions and support is limited as a result of rushed deliveries and poor documentation. Additionally, I'm suggesting what works for me and has worked for me in the past.
I would strongly This Website
Related
How can I create a generic and common system of returning application code and response messages upwards when an API call is called?
For example, I have a User class in user.php. From the highest level of my application, let's say app.php we can call
$user = new User();
$user->register($params);
About 10 things can go wrong during that process:
user already exists
invalid parameters
etc..
I don't want to just return 0 or 1, I also want the caller to know what was wrong. Here are some ideas
Exceptions, which I seriously hate..
Return array responses, ie ['result'=>0, 'reason'=>'not unique']
What is the standard way of doing this?
You asked about the standard way of handling this kind of thing. Generally the best way to handle these sorts of errors is by using exceptions, your dislike of them notwithstanding. By using exceptions, you can get away with doing less work on each side of the interface (method and caller) when you add a new kind of failure condition. You get code that's easier to maintain and more resilient to change. It's also higher performance: exceptions have a performance cost, but only when you raise them.
Your approach of returning arrays or objects is also OK. But you'll have to adjust both sides of the interface when you add new conditions.
There's a writeup on this in the php manual here. http://php.net/manual/en/functions.returning-values.php
Below are two ways a service layer can be implemented in an CodeIgniter application.
1st method
1.send request to the controller
2.calling service layer methods from controller
3.return processed result data set(D1) from service layer to controller
4.then according to that data set controller demand data from model
5.model return data set(D2) to the controller
6.then controller send second data set(D2) to view.
2nd method
1.send request to the controller
2.calling service layer methods from controller
3.service layer demand data from model
4.model send requested data set(d1) to the service layer
5.after some processing return generated data(d2) to controller from service layer
6.then controller send data set(d2) to view.
What is the correct way of implementing a service layer in CodeIgniter? Other than these two methods, are there any other good ways?
if you can provide an example in Code it will be great
Please note, this is not necessarily the correct way of doing it, but I'm going to explain how a framework like might typically do it and then you can learn about other methods and decide the best one for your use-case. Therefore, I do not expect this answer to be the correct one, but I hope it imparts at least a little knowledge on how things are done before someone who actually knows what they're talking about comes along and chimes in (also to those people - please feel free to edit / downvote this answer :D). Finally this also has nothing to do with CodeIgniter but frameworks in general. Your question should not only be framed as framework-agnostic, but language-agnostic also.
So I'm going to offer an opinion here and that is of the fact that all modern frameworks, specifically in PHP, do not do MVC. Why is this important? Because we all need to be speaking the same language, and 'mvc' does not exist in PHP. That's a fact. Accept that and then we can move forward onto the bastardization of the concept that frameworks use; and CodeIgnitor is a particularly great example of 'MVC' bastardization; henceforth known as "mvc" with quotes.
The plus side is that frameworks like Symfony, for example, provide an initial opinionated architecture that at least contains some form of consistency across the application, and it goes something like this:
A standard HTTP request comes in and hits the front-controller, typically app.php or app_dev.php depending on whether or not you are in development or production; one involves a lot of caching that needs to be run on each change and the other doesn't - which is perfect for development.
A router matches the current url to a controller class and an 'action' (method) within that class.
The dependency injection part of the framework figures out what objects are needed for everything from the controller forward into the model layer and back, and either instantiates or prepares to instantiate them when needed.
The controller is instantiated with any required dependencies and the relevant method is executed. This is typically where you would start your development and 'hook your code in' to the framework.
This is where you decide on your architecture, however, the most important thing from both a developer perspective and business perspective (for lower costs for future maintenance) is consistency.
I personally prefer to ensure my code is decoupled from the framework. I pass in scalars taken from the request into an application-layer service, which uses objects from the model layer (passed-in via DI) to use domain objects. The point here is that domain objects are not directly passed into the controller, they are proxied through an application-layer medium, so you can theoretically replace the entire framework surrounding this and still, all you need to do is pass those scalars into this layer before they hit the model layer and it'll all still work (think CLI calls, no more controllers).
The application-level service uses any required Repositories, Services etc (and passes those scalars into them, remember the separation?), which perform business logic, (typically these are where your design patterns come into play on a day-to-day basis), and then return that data to the application-level service.
The service then returns the data to the controller and guess what? This is where frameworks tend to fuck up! Because there is no concept of a "View" in today's frameworks. There is only a template, and you pass that data to a template and bam that's it. So in your diagram, there is absolutely no concept of a view because that's not how things are done. And to be entirely honest, I'm still using templates because they're the fastest way of doing things, but until modern frameworks get their shit together and actually start using Views, we're out of luck and have to remain steadfast when confronting the fact that some (like Laravel) refer to themselves as "mvc" frameworks.
Note, Fabien Potencier explicitly states that Symfony was not an MVC framework - at least he knows what he's talking about there. Again, this is not purist, it's important we're all speaking the same, factually correct language in computing.
So, because you like diagrams so much, here's how some might do it with today's frameworks...
This is for an application that has the concept of a Review and Criteria for each Review. And don't even get me started on Symfony forms, they're so coupled to everything they're not a serious part of any architecture.
How many effing layers do you need? We already have "MVC", in DDD we have the concept of "Application", "Domain" and "Infrastructure" seperation, so get those two working together first, then this "service layer"? Do you really need another layer, or is the above enough? Things to think about...
See, you're not stuck with the framework / http request to get the application going as a result of this separation.
See the "services" in the above diagram? They're separated from the controller so you can throw scalars from anywhere and the application will still work. I think this will give you the separation you need. It's great to do things the right way, learn how to do it, and then learn how to control yourself and be pragmatic about it when it comes to the business and it's needs, but frameworks need to sort their stuff out - and you certainly wont be writing lovely code with CodeIgniter ;)
Dependency Injection and the Adapter pattern would be a good place to start.
CodeIgniter support's neither out of the box, so you would need to write a wrapper or maybe a hook.
Your view could only support xml|html as json would need to be pre-rendered to a .json file and then returned as output but this would need to be done via code, it's easier just to return the object in that case and altered on the frontend. PHP is an embedded language which works with (xml|html)
A service model works best when it is injected(dependency injection)
into a controller/model and is listed as a property of that controller/model.
The service is then bound to an interface
For example facebook/twitter
They both have a request and response function but both follow similar patterns, yet have different endpoints.
interface SocialMediaAdapter{
public request(url);
public response();
}
public class FaceBookProvider implements SocialMediaAdapter
{
public request(url){
}
public response(){
}
}
public class TwitterProvider implements SocialMediaAdapter
{
public request(url){
}
public response(){
}
}
public class SocialMediaServiceProvider{
protected $provider = null;
public function constructor(SocialMediaAdapter $provider){
$this->provider = $provider;
}
public function fetch($url){
return $this->provider->request($url);
}
}
Dependency Injection required here
new MyController( new SocialMediaServiceProvider ( new FacebookService ) )
IMHO there is no right or wrong here:
option #1 -
If you want to re-use the service layer in multiple controllers / actions
and feed it data from different models based on the request it makes sense to go for the first one.
option 2# - However the first option could be problematic if your data model is more complicated. What if a second call to the model is needed based on the data of a first call? Using the controller for this business logic defies the whole purpose of the service layer. In this case it might be better to go for the second one.
I think the second one is the more common one.
You should use first one. Because in MVC web application, controller is used to separate your business logic from view, it's something like a gateway. You need to start processing your info using controller, from controller you should call model or service layer or anything you need & finally you should return back data to any other source from here. Your view or service layer should not directly access model.
I've recently started to work on an application based on the Kohana framework that has been in development for some months, and the code is not using any DB transactions. I've already seen data corruption because of this.
Going through all the code to add transactions manually would be a lengthy and error-prone task, so my plan is to implement something like the declarative transactions in the Java EE and Spring frameworks: simply wrap every controller action in a DB transaction using the before() and after() functions of the project-specific controller superclass. Maybe make it configurable via an overridable property containing the names of actions that require a transaction.
Has this been done before in a reusable way?
How can I deal with exceptions? Is after() called when an exception occurs? If so, how can I find out whether an exception was thrown? If not, how else can I react to them?
It doesn't look like Kohanas ORM has transaction suport but you can still makes the calls manually
$db->query("START TRANSACTION");
$db->query(query1);
$db->query(query2);
$db->query("COMMIT");
I had a look and it seems like the after method is not called if there is an exception, if you have a look in here and search for 'after' you get to some code where you see the catch statement doesn't run the after() method.
Im really not sure what how you can make it global without other trade-offs...
Using the before() and after() functions of the controller base class worked for many cases, but I felt uneasy about not doing an explicit rollback when dealing with exceptions. Then I found that I was also getting an implicit rollback whenever an action called Request::current()->redirect() because that function does anexit, so after() never gets called.
My new and improved solution is to override Kohana's Request class, and I create a Kohana module so everyone can use it easily:
https://github.com/brazzy/kohana-transactional
The whole "when to throw exception or return value" questions has been asked a lot (see the following to see just one example):
Should a retrieval method return 'null' or throw an exception when it can't produce the return value?
and I completely agree with the answers in main.
Now my question arises from adding a little more context to the above when applying this to a more complex system. Ill try and keep this as brief and simple as possible.
Right we have an example MVC PHP application:
Model A: has a function get_car($id) which returns a car object.
Controller A has a simple function for say showing a car to the user
Controller B however has a complex function that say gets the car, modify it (say through one of model A's set functions) and also updates other tables based on some of these new values through other models and libraries throughout the system - very complex ay lol
we now get to the main part of my question:
For data integrity I want to use MySQL transactions. This is where I run into a "what's best / what's best practice" scenario...
We write Model A to return FALSE if the car is not found or there is an SQL error.
This is fine for Controller A as it just wants to know if there was a error and bom out, so we just check the return value an bom - fine.
We now get to Controller B. Controller B say does some database updating before the Model A function is called which we need to roll back on error so we need to use a transactions. now this is where I get to my problem. do I leave Model A as a return value and just check it or do I change it to throw exception with the knock on effect of then having to also re-write Controller A as we now need to catch the exception... then (not done yet ;o)) do I roll back in the catch of the model (but how do we know if a transaction has been used or not?) or do we catch and re-throw or allow to bubble up to the controller catch and do the roll back there?
what I'm trying to say is that if I have lots of models and controllers with database interaction should I just make them throw exceptions and then wrap all my other code eg controller functions in try catches encase the model or library functions ever throw, or, do I make the models "self contained" to tidy and handle there own problems but then what do I do about rolling back a transaction if (for this "call") one was open (as per my example above not every time is a transaction opened...)? if this was the case I would have to make all my functions return something and then check this in the controller, as this is the only place that knows if there is an open transaction or not...
So to clarify I can use a try catch to catch and roll back in a controller, that's ok, but how to I do this from "further down" eg in a model or library function... that could be called both during and transaction or just as an auto commit normal MySQL call?
An explained answer would be great (as I like to understand why I am doing something) but if not a some vote for the favourite of the follow solutions (well the solutions I can see):
1) make all model and library functions always return a value and then the controller can either just bom or do a try catch to roll back where necessary - but meaning that I would have to check the return value of every model and library function everywhere they are used.
2) make all model and library functions throw exceptions (say on SQL error) and wrap every controller (which would call the model and library functions) in a try catch where the catch would either just bom or roll back if necessary...
also please note "bom" is push user somewhere or show a pretty error (before someone says "its bad practice to just allow your application to die..." lol)
I hope you get where Im coming from here and sorry for the long loooooong question.
Thanks in advance
Ben
[There's a theoretical problem implicit in the "For data integrity I want to use MySQL transactions"... since MySQL historically hasn't been very ACID - PostgreSQL and Oracle both provide stronger support for ACID. However, back to the real question...]
Both your (1) and (2) focus on exceptions versus failure-return values, but my impression is that this isn't the key part of detangling exceptions, error returns, and open transactions (and some databases support SQL exceptions as well). Instead, I'd focus on keeping the transaction state tied to the nesting of the functions manipulating the model. Here are some thoughts along this line:
You will probably always have error returns from some library functions anyway, so having Model A return FALSE isn't really breaking the paradigm, nor is there anything particularly troublesome about a mix of error returns versus exceptions. However, error returns MUST bubble up correctly - or be converted to exceptions if they go beyond what can be locally address.
Nested transactions are the most obvious way to have one controller start a database manipulation and still call other stuff in the app that also uses transactions. This allows a failed sub-sub-function to abort just its own part transaction and take either the error return or exception approach to bubbling the error up on the non-SQL side while the closed sub-transactions still maintain reasonable matching state. This usually needs to be simulated in code outside of the database (this is essentially what Django does).
Your code could start a new (potentially large) transaction, and keep track of the fact that it's already open to keep the sub-sub-functions in your code from trying to reopen it.
In some databases, code can detect whether a transaction is already open based on the database session state, allowing you to check the DB session state instead of tracking it in code.
Both of the above allow one to use savepoints to simulate truly nested transactions.
One must be very careful to avoid calling SQL calls with implicit commits (CREATE TABLE, for example). MySQL probably deserves a lot more caution around this issue than, say, PostgreSQL.
One way to implement the one big transaction approach is to have high-level function that initiates the transaction and then itself calls the top of whatever Controller B needs to do. This makes either bubbling up errors or having a special abort-transaction exception pretty straightforward. Only the top function would call commit rather than abort if no subfunction failed and no exception was caught. Subfunctions wouldn't call commit.
Conversely, you could have all of your functions pay attention to transactional depth implemented in the non-SQL side (your code), although this is harder to set up in some languages than others (it's pretty easy using decorators in Python, for example). This would allow any of them to call commit if they were done and the transactional depth at zero.
Hope this helps someone :-)
I have been using Magento & PHP CodeIgniter MVC for about 4 months. I am having a peculiar problem understanding where to set the validation logic for both CodeIgniter & Magento, only if I consider to follow the MVC architecture to its true nature & in a very proper semantic way.
First of all, I will start off with Magento:-
Say I have a "Assignment" module in Magento, which is about Players & Tournaments both. I have 3 action methods, in this "Assignment" module's controller, where I need to check & validate the following:-
Player ID
Tournament ID
This validation is also required in the "Assignment" module's Block class, along with in the 3 action methods.
So my query is should I write the validations for the above 2 points in this module's Controller class or in the Model class, because I will need to use the validations both in the Block class & also in the Controller class?
Also what does actual MVC architecture suggest in this case?
If possible, please provide a code snippet, highlighting the logic of your implementation.
Regarding CodeIgniter or any other PHP MVC Framework:-
Since Validation of anything using sessions is quite page-specific & since there is no concept of Blocks in CodeIgniter, so normally session validations & setting of session variables are done in the Controller class only.
So my query in this regard is that is this a correct approach & under what circumstances should I put setters of sessions & session validations in the Model class?
And again, what does actual MVC architecture suggest in this case?
And again, if possible, please provide a code snippet, highlighting the logic of your implementation.
I am really in confusion state regarding this & I'm sort of stuck in here. Please help me in here. Any solution / help is greatly appreciated. Many thanks in advance.
EDIT:-
If possible, please provide some Magento code on how to create & write proper Validations, along with throwing Exceptions, with the actual Exception messages defined in the Model methods?
The Model layer should be able to maintain its own consistency, so regardless of other decisions, you should include your validations in the Model layer. To help the user (and provide more helpful validation messages), you may also wish to do some validation in the controller level.
The advantage of this approach is that, assuming you maintain your model layer, there is no chance of a rogue controller setting bad data. This plays into your second question, for which the Magento answer would be to use an object to manage data in parts of the session, and to validate that data on the way into the session.
As an aside, to deal with validations in your Blocks/Views, consider using validation like this. It has its own flaws, but generally minimizes the amount of validation code you have to write:
// make sure that the below returns the relevant assignment model class
$assignment = $this->getAssignment(); // or get it via a session, or helper, or what have you.
$player = getChosenPlayer();
try {
$assignment->setPlayer($player); //throws exception when invalid
... do more ...
$assignmnent->save();
} catch(SomeException $e) {
addValidationError($e->getMessage());
renderPageAgain();
}