This page discusses the advantages and disadvantages of using the Views module versus custom coding your queries and presentation.
Custom code advantages
Having custom code offers the following advantages:
- Complete control over the data fetched. Some SQL queries are difficult to replicate in Views.
- Some opportunities for query optimization might exist when writing custom code. Views is as efficient as a general tool can be, but the specific details of your target query might mean that further optimization is possible.
- Complete control over presentation. You can specify all the presentation details for your data.
- Complete knowledge of your code. If you write it yourself you know what it contains. Compare this to the task of studying the Views codebase.
- Simplicity. In many cases all you need is a menu, a callback and a simple theme function to render the fetched data. In less then 30 lines of PHP you can fetch and display a list of nodes. Compare that to the huge amount of views-code, including plugins and interfaces to manage a similar list.
- Revision control systems like CVS, SVN. If your view is stored in the database you risk losing it if the database becomes corrupt. Note that you can export views to PHP code and put them in custom modules, though, so this one equals out.
Using the Views module offers the following advantages:
- Change behavior without changing code. You can alter your application at runtime without worrying about breaking code or making a PHP syntax error. (Note: since views that are stored in the database do not have revision control, changes made like this cannot simply be undone... be warned)
- Many options for presentation. Different view types mean that you can change the presentation of the data you fetch.
- Black box. You don't need to write or read any PHP code to get started with Views.
- Data safety. Malicious users can do a lot of damage without proper data safety testing. Views goes through the trouble to scrub all data it presents, so you can feel assured that as long as the module providing the data properly implements the Views API, its data will be safe.
- Open architecture. If you are a developer, you can write to the Views API and add features, presentation styles and behaviors to Views in custom modules. These are then reusable in other views that you later create.
- Community benefit. You will be the recipient of an enormous amount of Views code that is being contributed and improved by the community. There will be Views features available tomorrow that weren't here today. There will be people fixing Views bugs while you sleep. This won't be the case for your custom code.
- Reuse views. Build a basic view that does something useful, export it, and then use it on the next site you build.
- Tight integration with other modules that you might already be using. Every contrib module can potentially extend Views, so make sure and take inventory of what modules you plan to use when evaluating Views on its own.
- Panels integration. Panels is especially powerful and the Views integration is very good.
- Programmatic handling of views. You can instantiate Views objects in PHP code and manipulate them in many ways. The Views API provides several points of access to the Views object, so if you are really unhappy with what you can achieve with the Views UI, you can take control of the object itself.
- Documentation. There is more documentation about Views than there is about your custom code.
- Page, menu and block integration. Views gives you page views and block views, and lets you instantiate menu items as well.
- Exposed filters: Views gives you a lot of control over creating form elements to filter your view. Writing FAPI code is bulky and verbose. Creating all those dropdown selects, autocomplete text fields and checkboxes is a lot of work. You can still use formalter to get to the exposed filters submission and validation handlers, so you don't lose any control by going with Views here.