Coming from ZendFramework 1 to ZendFramework 2 I'm a bit confused as to the functionality of the modules. In ZF1 a module was a sub-application, so you'd have a 'default' module and maybe an 'admin' module that would handle the administration section of the system and there'd be models, views, and controllers underneath each of those modules.
It seems that in ZF2 a module is more fine-grained? In the tutorial project they created an "Album" module which seems like it is only configured for a single controller. What if you wanted to maintain users and they each had a bunch of albums? Would you create another module for 'Users' with it's own controllers/views/models, or would you create a 'UserController' inside of the 'Album' module?
What if you wanted to provide an api endpoint into those controllers? Is that yet more modules, or do you provide a route in the album controller pointing to '/api/album' which specifies a rest style controller?
Zend 2 takes a modular approach to everything. It is really up to you how fine grained you want your modules to be. If album and user are decoupled and could be reusable then it makes sense to have them in separate modules. Since an album may not ALWAYS have users and vice versa. However if you write the code in such a way that user and album are tightly coupled they might as well be in the same module. zf2 is very flexible and this is really a design decision you need to make
With regard to your API question I would say you would have the Rest controller and the controller in the same modulle and use the module config routing as you say
Related
How can I manipulate other modules without editing them ? very the same thing that wordpress modules do .
They add functionality to core system without changing the core code and they work together like a charm.
I always wanted to know how to implement this in my own modular application
A long time ago I wrote the blog post "Use 3rd party modules in Zend Framework 2" specifically about extending Zend Framework 2 modules. The answer from Bez is technically correct, it could be a bit more specific about the framework.
Read the full post at https://juriansluiman.nl/article/117/use-3rd-party-modules-in-zend-framework-2, but it gives you a clue about:
Changing a route from a module (say, you want to have the url /account/login instead of /user/login)
Overriding a view script, so you can completely modify the page's rendering
Changing a form object, so you could add new form fields or mark some required field as not required anymore.
This is a long topic, but here is a short gist.
Extensibility in Zend Framework 2 heavily relies on the premise that components can be interchanged, added, and/or substituted.
Read up on SOLID principles: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Modules typically consists of objects working together as a well-oiled machinery, designed to accomplish one thing or a bunch of related things, whatever that may be. These objects are called services, and managed by the service locator/service manager.
A big part of making your module truly extensible is to expect your developers to extend a class or implement a certain interface, which the developer register as services. You should provide a mode of definition wherein the developers can specify which things he wants to substitute, and/or add their own services to -- and this is where the application configuration comes in.
Given the application configuration, you should construct your machinery a.k.a. module services according to options the developer has specified i.e., use the developer defined Foo\Bar\UserService service as the YourModule\UserServiceInterface within your module, etc. (This is usually delegated to service factories, which has the opportunity to read the application configuration, and constructs the appropriate object given a particular set of configuration values.)
EDIT:
To add, a lot can be accomplished by leveraging Zend's Zend\EventManager component. This allows you to give developers the freedom to hook and listen to certain operations of your module and act accordingly (See: http://en.wikipedia.org/wiki/Observer_pattern)
I was wondering if there are any guidelines for the number of controllers to make in any web based frameworks. I know it depends on the requirement. But still if you would consider a basic application containing signup, login, user authentication, Sending emails, User Profile Edit etc..how do you decide about the controllers?
And if there are many common functions would you make a different controllers to hold them all? Some frameworks like Zend recommend to create helper files for that! Do you create category of helper files for different functions?
Looking at routing we have some sort of a guideline as to how many controllers and even actions we will have in Zend Framework. Although we have to keep in mind that we can do quite a few things to change this in one way (getting less) or another (have even more).
The basic and general rule in ZF for routing is to have a link path matching up with controllers and actions.
www.yourdomain.com/controller/action
Routing will dispatch to the corresponding controller and with it to the named action. When we follow this basic rule we will end up with a number of controllers that matches our number of paths we like to see.
You can basically create a root path for every piece of functionality for you website and end up with as many controller (with one action) or even combine everything within one path and hence one controller but as many actions.
Ultimately you will and should combine common features of your website into one path and controller, e.g. combine everything related to user management (signup, profile edit) into a /user path and UserController.
As for your examples I think User authentication is something that will not have its own controller but happen inside the Login controller or models used by that controller.
UPDATE
Controllers and their actions interpret requests and should only delegate to other methods. It may be beneficial to keep these methods in their own classes. How you structure this methods and classes is up to you. The Zend way is to keep them in your own application library, e.g. sending emails should be held and performed by a separate class in your own application library (next to and maybe extending Zend classes).
If you have a contact page you could have a /contact link with a ContactController. The indexAction will delegate everything to present the form page. The form could have a /contact/submit link for the submit button and a corresponding submitAction will hook up your email library class and send out the email. The submitAction finally may call something like _redirect('/submit/thankyou') or even /submit/error. As you may guess by now there will be a thankyouAction responsible for presenting a Thank you page or a errorAction to let the user know there was an error.
Do you have it as a separate Module, or just one separate Controller, or multiple Controllers without any logical separation from Frontend (except for Auth ofcourse), or something else?
Assuming that backend is reasonably complicated, i.e. something more than review/confirm/delete comments for your BLOG.
Definatly belongs in a new module then it is easy to create a separate layout in my opinion.
In a recent project a colleague created a separate admin controller in each module with the layout defined in an admin module. This way he could drop in/remove modules from the project with the main admin module autodetecting which modules are installed and creating menus based on the admin controller found in each pluggable module.
I have explained that poorly, but it's a good system.
I would create a separate module. Otherwise you might run into context issues because the ArticleController in the frontend should have other/limited functionalities then the administrative ArticleController and you end up implementing mixed controller classes (bad idea!) or prefix the administrative class.
So having multiple modules makes it easier to separate different concerns.
(Plus it will make it easier for you to implement an ACL and handle the corresponding resource/role definitions.)
I'm a bit puzzled about Zend Framework modules.
I mean - I understand that you would usually want to have frontend and backend module... right?
But - What else would you separate out into modules?
can someone who uses Zend Framework professionally give an example of what modules they have in their application?
In the Zend MVC lingo a module is an independent part of your application. For example if you want to write a Content Management System you will probably have different modules like
Main application (user login, application bootstrap etc.)
Blog
News
Admin panel
Image gallery
Basically each of these modules could act as a separate application (although they will eventually be interconnected). The module approach also gives you an easy way for permission management (e.g. users can only pay for using certain modules).
As addition to Daffs answers we could try to figure out some guidelines for deciding between choosing a 'controller' or a 'module' to implement a certain bundle of functionality. Please help making this list comprehensive by commenting or editing:
When to use a 'controller':
when there is a considerable degree of dependency on different models of the same module
when there is a considerable degree of interaction with other controllers of the same module
when the functionality can be covered with a few methods/actions
when the functionality is clearly just a bundle of subordinated functionality of the given module
when the functionality can be easily maintained together with the rest of the code (versioning, deployment, ...)
When to use a 'module':
when there are no or almost no dependencies with the main modules controllers and models
when the bundle of functionality can be seen as a separate (sub)application
when the functionality can't be covered with a few methods/actions and thus has to be broken down into several controllers
when versioning and deployment needs independence from main module
I am building a site in ASP.NET 4 and MVC2 that will have premium features, such as SMS notifications that will only be available to paid subscribers. I also have additional modules for things like Inventory, and Transactions etc
I am already leveraging the standard MembershipProvider, and am leaning towards using Roles tp provide this functionality.
ie: have an "SMSModule" role that the user gets if they pay for the add-on SMS service
This makes the controllers simple with a little attribute decoration, but the problem I see with this is that there will be a bunch of conditional code scattered through my views etc
Is there a better method of providing a "module" style approach in .NET 4 and MVC2???
You can add your conditional logic to view models, use the controllers to set the viewmodels appropriately and it should be fine... Sometimes you have to have the if statements inside the views even if not so ellegent. Unless of course you are using a view engine like spark then your if statements are placed in another unobtrusive location, but they still exist! You can always create HtmlHelpers and set the code to the serverside and based on the logic display appropriately...
FWIW I ended up using a combination of Descriptors in Spark View Engine, along with a custom Feature provider and associated ActionFilter