Welcome Guest, Not a member yet? Register   Sign In
Advice on web application design
#1

[eluser]panos konstantinides[/eluser]
Hello I have a design issue and I would like some advice from the more experienced developers in here. I have a use case where I need to update a user in the database. Before the update takes place I need to call an external web service. So the total flow of the system is

1) Check if the user can be updated by doing a SELECT in the database
2) If it can then call an external web service.
3) Parse the XML response (using DOM)
4) Update the database with the response.
5) Return a success or failure message.

What is the best way of implementing it? My colleague argues that I should implement all this functionality within a model and the controller should just call this model and then load the view. He argues that the controller should be confined to a maximum of ten lines per every function. I am reluctant to put everything in the model since this makes the model convoluted and it looses its original meaning, that of data manipulation only.

I come from a Java background and in the MVC frameworks I would use a custom class that does all this (and then the controller would just call this class), since the models are only a representation of data and do not contain lots of logic.

So now I am in a dilemma. Do I put all the logic in the model? If not, do I put it in a helper class? In the controller? Somewhere else? Any help is appreciated.

Regards

Panos
#2

[eluser]renownedmedia[/eluser]
I'd put the two database functions in the model, and the web service interaction in the model.

So it would be like this (C = Controller, M = Model):

C(init) -> M(db_select) -> C(check_result) -> M(web_service) -> C(parsing) -> M(db_update) -> C(message)

That way, the higher level logic is handled in your controller, and all the little data interaction components are done in your model(s).
#3

[eluser]panos konstantinides[/eluser]
Hello Thomas, thank you for your prompt reply.

By doing what you suggest don't we add unsuitable functionality to the model? Maybe this is a separate question: what is the role of the model in CI? The user guide says that "Models are PHP classes that are designed to work with information in your database" so it might seem unproper to put non-database specific functionality in there. Any more thoughts?

Regards

Panos
#4

[eluser]InsiteFX[/eluser]
Your model handlles all of your business logic...

Enjoy
InsiteFX
#5

[eluser]renownedmedia[/eluser]
Models don't have to handle all of your business logic. I prefer to let my controller control my logic.

For models, I use them as an interaction with any sort of data, so that my controllers can be clean and my models be dirty. Like, some model functions will return an array from a db, some will return a single scalar value.

This keeps the clean business logic in the controllers without having to worry about data storage conventions!
#6

[eluser]panos konstantinides[/eluser]
Thank you for your replies guys, I appreciate it.

If anyone has anything else to add/comment by all means please do.

Regards

Panos
#7

[eluser]BrianDHall[/eluser]
I consider my models as The Keepers Of Application Data. As such they handle all the storage, retrieval, care and feeding of such data, including common manipulations of it. After all, how data is, say, processed into an XML file is utterly dependent on how that data is structured to begin with, so where else but in the model should it be?

I would handle your issue as simple as calling $user_model->safe_update($userid). The safe_update() function would process step 1 through a user_updateable() to ensure it can be updated, if true then proceed to 2 of calling a web service.

How that web service is called might actually be the work of a different model, or even a library. I depends on what it is, exactly, and if you might want such calling and retrieving functionality to be used for other things in your application.

For step 3, this is the work of an existing library or PHP function set, such as SimpleXMLElement, which is likely so simple it doesn't take anything special to do it. For the logic of what is interesting and what isn't (probably what you meant by parsing...), that would be back in the model in a parse_xml_response($xml) function.

Step 4, definitively a model function.

Step 5, certainly a model function, but it is up to your controller to determine what to do with the result.

So in the end your controller would probably only have:
Code:
//...update requested...
$this->load->model('user');

$result = $this->user->safe_update($id);

if ($result)
{
//...update successful...
}
else
{
//...failed...
}
#8

[eluser]panos konstantinides[/eluser]
Hello Brian so you also agree on putting the business login in the model, or at least in a few different ones.

I will also go with this technique then, putting all the business logic in the model.

Thanks again everyone for their input.

Regards

Panos
#9

[eluser]wiredesignz[/eluser]
Business or Domain logic belongs in the model. Check this article which explains the different component roles in MVC.

http://www.phpwact.org/pattern/model_view_controller
#10

[eluser]panos konstantinides[/eluser]
Hello wiredesignz, the truth is that I'm thinking more in a Java context where the database entities and the handler of these entities (lets call it the service layer) are two different things. So you have the entities (EJBs, entity beans, or POJOs with Hibernate/Toplink), which represent the domain data (they have no logic at all), and you have the service layer (a bunch of Java classes) which contaisn the business logic and handles this data. Then the controller makes calls to the service layer. So the Model in this context is *both* the representation of entities as Java classes and the service layer.

But I think in CI (and correct me if I'm wrong) the notion of separate database entities as objects does not exist and therefore the representation and the manipulation of database data is happening in the same class.




Theme © iAndrew 2016 - Forum software by © MyBB