I have lots of auto completes like City, country, companies, brands, people names, etc. Now my team is currently giving each autocomplete a separate model in codeigniter. The issue i have is then each autocomplete has its own code. I want to make it templatized so there is only 1 code base for all auto completes and it pulls the autocompletes in and out dynamic.
Is it possible or is the way my team is doing it the correct way?
Your CI models should be organized to reflect your domain, so in the case of cities, countries, companies and such, each are different entities and deserve a seperate model. More files does not mean it is less maintainable.
As for autosuggest, your model simply needs to deliver the data to a controller that will be called using Ajax. You can do the json_encoding of the data stream in the model or the controller, I prefer to use the controller.
So eventually yoiu hopefully have a single autosuggest plugin in the front-end that simply calls different controller URLs. These controllers know which model to use to get the autosuggest data.
This is a clean seperation of duties, and maintainable.
Related
I have just started an MVC project for the first time, and I have encountered a problem that I really wasn't expecting: Too many models.
Not too many different models, but too many which are subtly different, but almost exactly the same.
I have a fairly complex page, with several combo boxes, a list of detail objects and some other extraneous unrelated things that I need to keep track of. More information goes to the view than I get back (which is fine).
I have a domain model, which has remained constant throughout. (1 model)
I have a single use view model, which is the domain model and some extra information wrapped round it. (1 model)
I have a single use form model, which is a copy of the view model with an empty shell copy of the domain model inside it with validation stuff on it. (2 models)
I needed to change the type of a property this afternoon, and I had three separate places to change it in. It seems that I have too many models which are single use. It seems so much work for something that was supposed to be much easier than classic ASP.NET.
My question is: Am I doing it right? Are there supposed to be a multitude of models, or am I missing something obvious?
Not entirely sure what the form model in your example is for - are you using that to limit the post-able fields from the client or using that to map in to your domain?
In my own MVC websites I will have a domain model (which may just be a local domain or come from a remote WCF service) which I map one to one in to my individual ViewModels in order to render on screen and receive the post back. These also contain my validation (be it annotations or fluent etc).
Any property name changes would then be restricted to just the relevant page's ViewModel and the domain.
If you're in a situation where you're replicating properties between domain models then some sort of base view model structure would serve you well for common entities but on the whole it's not something I find to be a massive overhead personally.
This is more of a non-code related question. I want your experience here and suggestion. I am designing this simple web application where I could just insert data, and then making sure the website will view that data based on categories.
In my controller, I have functions, each loading based on which category is selected from my main page.
Now I am wondering, is it better to create multiple controllers (like I used to have separate classes when using OO Php) for say CRUD operations, Listing the records, Search functionality, etc. Or just keep it all centralized in one controller (the current approach)? If multiple controllers, any recommendations?
You should have a controller for each separate functionality your websites provides.
For example:
controller for handling "regular" content (articles) (displaying articles, searching, rating, etc)
controller for handling user management (login, logout, registering, etc...)
controller for "static" pages like about, help, tos, etc...
And you should also handle all database operations in model classes, each for different entity (model for articles, model for users...)
I hope you got the point
Codeigniter uses an MVC structure, so you should actually use models for database operations, and separate them in a way that each model is used for a specific functionality.
If all the categories are handled the same way, you should add all the retrieving from db code in a single model, that way you simplify your code making it a lot easier to maintain.
I have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
I have a question concerning the structure of an MVC application. Suppose we have to realize a web-based application composed by several modules, such as shopping cart, store browser(end-user), store manager(admin) and so on.
It is of course possible to create one controller and use the routing to submit the requests to a specific controller's action method. However this would make the code quite messy and hinder the practice to vertically structure the application, namely to identify and distinguish which views, models and controllers are involved to fulfill a specific requirement (an example is given by Phil Haack).
Another approach is to use one controller for each application section, for instance one controller made available for end-user operations, another for the store administrator, another one for queries made by the shipping department and so on. The drawback to this approach is to have too many controllers that mess up your code, too dedicated for specific tasks and so difficult to reuse.
According to this two extreme situation, what is the best way to organize your controllers and routing policies? Do you use a structured approach or it depends on the type of application you are developing?
Thanks
Francesco
It is of course possible to create one controller and use the routing to submit the requests to a specific controller's action method. [...]
Another approach is to use one controller for each application section, [...]
You're overlooking a third alternative, which is the most common one. In general you should have one controller per resource. A resource is a model that is publicly exposed. In your specific storefront application, the resources would be things like Products, Orders, Customers, etc.
This is typically the proper level of abstraction, because controllers usually don't need to know about models other than the resources they touch. A controller that touches more than one resource should be viewed with some skepticism, since it's violating the single-responsibility principle.
You should try to follow REST as much as possible
Basically - that means controller for each 'collection' (Your entity).
If Your controllers will be RESTful, other parts (routing, views) will fit themselves accordingly.
Hey guys - here's a question on Zend Framework or better on MVC in general:
I am asking myself for a quiet a long time now, if it is a good idea to push business objects (User, Team, etc.) to my views or if it would be better just to push dump data containers such as arrays to the view for rendering.
When pushing business objects to my view I have a much tighter coupling between the views and my domain model, however, the view could easily do things like foreach($this->team->getUsers() as $user) { ... } which I personally find very handy.
Providing domain model data in dumb arrays to me looks more robust and flexbile but with the costs of that the view cannot operate on real objects and therefore cannot access related data using object's method.
How do you guys handle that?
Thanks much,
Michael
It's better to make your View access a Domain Model object in an object-oriented manner, instead of using the Controller to convert Model data into plain scalars and arrays.
This helps to keep the Controller from growing too fat. See the Anemic Domain Model anti-pattern. The Controller only needs to know what Model to instantiate, passes the request inputs to that Model, and then injects the Model into the View script and renders. Keep in mind that a Domain Model is not a data-access class.
You can also write View Helpers to encapsulate a generic rendering of a Domain Model object, so you can re-use it in multiple View scripts.
Your View should accesses the Domain Model only in a read-only manner. View scripts should not try to effect changes to the Domain Model.
You can also design your Domain Model to implement ArrayObject or other SPL type(s), as needed to make OO usage easy in the View script.
It's true, a large driving motivation of MVC and OO design in general is decoupling. We want to allow each layer to remain unchanged as the other layer(s) are modified. Only through their public APIs do the layers interact.
The ViewModel is one solution to abstract the Model so that the View doesn't need to change. The one I tend to use is Domain Model, which abstracts the details of table design, etc. and supplies an API that is more focused on the business rather than the data access. So if your underlying tables change, the View doesn't have to know about it.
I would expect that if there's a change to the Domain Model, for instance it needs to supply a new type of attribute, then it's likely that your View is changing anyway, to show that new attribute in the UI.
Which technique you choose to decouple one layer from the others depends on what types of changes you expect to be most frequent, and whether these changes will be truly independent changes, or if they will require changes to multiple layers anyway.
The "standard" approach would be to completely prepare the model in the controller (e.g. fetch all teams, including users) and then send that to the View for presentation, but you are not bound by that. The data structures can be whatever you want it to be: Array, ArrayObject or custom Classes - anything you deem appropriate.
I dont use Zend framework, so this is in repsonse to the general MVC Have a look at the ViewModel pattern.
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx
I'm comming from a .Net MVC point of view but I believe the concepts will the same.
I will do all my view rendering in the controller bascially like below
model only output dataset/objects (this should contain the most code)
controller assign view and add necessary HTML and make use of models
view only contains placeholder and other presentation stuff and maybe ajax call
So my team can work on each part without interrupting each other, this also add some information security to the project i.e no one can retrieve all the working code they only communicate by variables/object spec.