What is the right approach to set up modules in Zend Framework 1 based application

Question

Hi guys I'm a bit confused on how to use modules within my Zend Framework based application - from what I've read up on modules work as sub application within your application however where does the line blur between what goes into a module and what can be handled within the controller. Like for example in a Home booking application you have the following features:

House management Rate Management Booking online + booking management

Consider that we have three types of users an admin user, a customer who makes the booking and a landlord who owns a house set up for booking how would be set up our modules i.e would we have something like:

admin
->controllers
  ->houseController
  ->rateController
  ->bookingController
  ->customersController
landlord
->controllers
  ->houseController
  ->rateController
  ->bookingController
customer
->controllers
  ->bookingController

or would it be something like:

modules
->Booking
->Rate
->Customers

The latter format seems a bit like turning controllers into modules - whats the right approach here?

In the original listings - there are repeated controllers in each module. Pretty much the difference is quite minute eg: houseController for instance in admin module - administrators can view all houses by all landlords while landlords can view only their own houses. Technically I'm repeating 90% of the code here which doesn't seem like the right thing to do as I don't think you can use ACL to restrict the listings that can be viewed. What is the right approach here for this logic?

Answer 1

While the question is old I feel it still hasn't been answered. I myself have been setting up an e-commerce CMS project for the last few days and learning the basics of Zend Framework coming from a silver light Prism background. One thing that I can suggest is to understand that a module doesn't need to be small. The very definition of a module is "An independent self-contained unit" so in your case you'll have a "BookingModule" that when finished should be able to be chucked into any application and then with the proper tie ins can communicate with other modules. The issue with your layout is your relying on the modules to separate your different levels of access (which in a reply you basically ask "how should I do this"), what you want todo is use some sort of Authentication method to see if the current user can run a specific action. Off what you've given us I'd suggest a role based authentication method with maybe multiple actions (still deciding this part for myself).

Zend Framework

• Hosts an "Application" which contain modules that utilize MVC

Module

• An independent self-contained unit that can be plugged into any application
• Can have hooks/tie-ins to communicate to other modules within an application

MVC

• Models: Insure Data integrity through Validation verification
• Views: Displays the Model's Data to the user
• Controllers: Process user input through Actions that edit Data
  • Action: Security logic should go here, to ensure the user can use this action.

Role

• An Enum for use in Authentication

TL;DR For your project you should have 1 module, 4 controllers, 3 roles and an authorization Service tied to your controller's actions to verify the current user can run said action. This'll prevent repeating code and also allow it to be expandable without any code rewrites.

Read this to understand Authorization on Actions: Activity based checks

Edit: Should probably note that there is nothing wrong with making each one a module as it is workable, its just more work to tie in and more coding with the only gain being you could pull say the Bookings Module into a completely different Application without the need for the other 2. But from my understanding you just want 1 module

Answer 2

it looks to me as if most of this functionality would be more appropriate to the models. you might be able to get away with just the default module with a property controller with different views for customers and owners with maybe a separate module for the admin as admins usually have more functionality required for management.

//bare minimum, you may need to add controllers andd models for user/owner objects and rate managment
/application
    /controllers
        /IndexController // default entry to application, login, authentication
        /ErrorController
        /PropertyController // actions to view, book and reserve a property object, may provide some extra functions for owners.
    /modules
        /admin
            /IndexController // provides actions for administration activities such as managing user and owners and setting ACL and Authentication.

This is just my opinion, keep in mind that modules in ZF1 are a completely different animal from modules in ZF2.

Answer 3

ok. let's try to answer it...

this is a classical optimization challenge (regarding the application architecture). based on what your goal is, you will have different optimization approaches. I prefer to optimize application architecture regarding resulting technical functionality. if the functionality of your desired modules

• admin
• landlord
• customer

have different functionality scopes, keep them separated (this will also simplify ACL definition).

based on what you have posted in your question there is some controller "overlapping":

• houseController
• rateController
• bookingController

they are used multiple times. functionality wise, they should be used only in one module. if you can not separate them, there is no need for separate modules...

hope this gives you an overview on how to use modules.