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.
Related
I have read a lot of gwt-mvp questions that are asked here, but since i'm totally new to this design pattern I would like to ask some questions:
[1] The Activity-Place pattern is a different pattern than mvp?
[2] In the MVP pattern presenters contain the logic. Now the logic of the widgets/controls is defined in the Activities?
[3] The CustomPlace classes are fixed (as the Eclipse plugin constructs them) or can i put data/methods and what kind?
[4] What is the use of the Presenter interface inside a CustomView? What data/methods would make sense to add into it?
[5] I want to build an application that will use many data structures that will be saved into a database. I have read some other posts here and I will make the Model part of MVP live inside each Activity. So i think to create each time the data structures of each activity at start and load its values (if necessary from db) and will update the database after the user goes to another view. What do you think about this approach?
Let's start by debunking one myth: Activities/Places have nothing to do with MVP. Places is about navigation, Activities are about "componentizing" the UI wrt Places. On the other hand, MVP is a design pattern, it's about how to organize your code.
Many people are using their activities as their MVP-presenters, but it's not enforced. The GWT team is trying a new approach where the activity is distinct from the presenter (work underway in the mobilewebapp sample if you want to follow what's going on there). You could also have your activity being your view and making use of an "internal" presenter (similar to how Cell widgets work)
A Place is more or less a URL. You can put whatever you want in it. I'd suggest making places immutable though: build a Place, goTo it, make use of its properties to build your UI.
That's about MVP then. This is only needed to decouple your view and presenter, mostly to make mocking in unit tests easier (this is particularly of the view interface though, not much for the presenter one, unless writing a test harness for you views). In some cases, you might also want to use the same view with distinct presenters; they'll all implement the same interface so the view can talk back to them.
How about the closing of the window/tab? I'd rather use a periodic auto-save, or an explicit save button; and implement mayStop so it prompts the user when there are unsaved changes (similar to how most desktop office apps work —e.g. MS Word or LibreOffice—, and GMail if you try to navigate away before your mail draft is auto-saved)
The Activity-Place is an implementation of the pattern. Google introduced gwt-mvp pattern at Google IO, but only provided it's implementation as part of GWT about a year later.
Yes Activities contain business logic. No, widgets/controls usually do not contain any logic, they just fire events based on user action. The logic that acts upon those events is written by user and resides elsewhere.
I don't use Eclipse, so wouldn't know about Places generated by it. Normally custom Places can contain custom fields and methods. For example they can contain custom place token arguments, i.e. if place token is "#place:id1", than your custom Place could contain field holding this argument.
When View needs to call/access Activity, it does so via Presenter, which Activity implements. For example when user enters all data in a for and presses submit, then you could have a method in Presenter named submit(formData).
Preparing/loading data in activity.start(..) is a normal way of doing things. If particular activity is used a lot, then you might consider caching the data if appropriate.
It seems to me that as I'm working with View and Controllers, that Controllers only handle the first level of their respective folder.
/Controllers/MembersController
/Views/Members/
How is the Controller supposed to handle sub-folders?
/Views/Members/Business
The Controller isn't. If you want a page at the url /Views/Members/Business/ThePage, you'll solve that with a route definition in your global.asax.cs. If you need to put views in subfolders for organization, you should consider splitting up your controllers.
Update in response to your comment.
In short: yes, the routing definitions are responsible for choosing what controller should handle your request.
It seems that a slightly more detailed walkthrough of how the MVC framework was designed to be used might be in place. I'll keep this really basic, and skip all the stuff about the framework's internal workings. (That will make some advanced readers think I'm saying stuff that's flat out wrong. Please bear with me - I'm just being intentionally sloppy...) Here goes...
When a request is submitted from a browser to your web server, the MVC framework goes to the route definitions to see where the request should be sent. It looks through them in the order you define them, top first, so if there are several matches only the first one will be relevant. (Therefore, you want to keep your very general routes, like the default one, at the bottom.)
When the framework has decided that a route is a match, it looks up what controller and action the url should be routed to. It fills in all action parameters with data from the url, and calls the action method.
The action method on the controller is now responsible for being "the spider in the center of the web", that instruments everything that needs to be done to serve the response. This might include querying your model for data, calling various library methods for calculations or almost anything else. The final step of the controller method is determining what response should be returned - in most basic cases, the response should be a view, and the code for returning it is return View();.
The view (or whatever other result you're returning) possibly gets some data from the controller, and is then responsible for rendering this data correctly. When the view has done its job, the framework serves it back to the client.
As you can see, the decision on what controller action should be called is much earlier (step 1 and 2) than the decision on what the return result should be (end of step 3), and the two of them aren't even necessarily related to each other.
To reflect this in your application, you want to have a folder and file structure for controllers and views that corresponds to the available controllers and their action methods (at least those of them that can return a ViewResult), and a route collection that reflects what urls you want your user to use to get to these controller actions. By defining more routes than the default one, you can get quite a variety of url structures, without changing your controller/action method/view structure at all.
If all of this still seems like a labyrinth of decisions, it might be appropriate to go to http://www.asp.net/mvc/ and watch some of the learning videos or read some tutorials. There are some really good both videos and texts there about how the framework works, and how it's intended to be used.
In your controller action, you can return a view from any folder you want like this:
return View("/Views/Members/Business/Index.aspx", model);
If anyone is still interested in a solution, MVC has a thing called "Areas" that allow you to define subfolders.
http://msdn.microsoft.com/en-us/library/ee461420%28v=VS.100%29.aspx
I heard a bit about we should keep the code in controllers as less as possible. So where do we put those code?
This will depend on what code you are talking about. For example if you are talking about validation, this should go into the model, if you are talking about data access this should also go into a repository or the model (personally I prefer repository), if you are talking about a business logic this should go into a service, so that all that's left into the controller is to call this thing and pass the result to the view.
I would recommend you watching this video presentation about how to put your controllers on a diet from Jimmy Bogard.
Do you know thin and skinny controller? So my answer is if you put many line of codes in controller, your code will be messy and hard to unit testing. Really the controller only executing the actions related with current HttpContext, so if you have business logic, data access, encryption,... you must separation of concern. The reason you don't put business logic at here is business belong to domain. So delegate to Domain for processing. Controller must be consider all actions related to HttpContext (Session, ViewData, TempData, User in current thread, Global and Local Resources,... ) and delegated all other actions to other component. Rule of thumb is fat model and thin controller for cook delicious cake(phpcake).
Some links you can reference for skinny and fat Controller at here and here.
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
This seems like an elementary question, but after a lot of searching around I can't seem to find a straightforward explanation:
If I'm building a web application that is going to be accessed largely through a web browser, but that will also support some API requests in a RESTful way, should there be a large degree of separation between the two?
On one hand, it seems a large amount of the functionality is the same, with identical data presented in different views (HTML vs. XML/JSON). But on the other hand, there are certain things I need to present to the browser that doesn't quite fit a RESTful approach: how to get an empty form to create a new instance of a resource and how to get a pre-populated form to edit an existing resource.
Should these two different methods of accessing the system by funneled through different controllers? Different methods in the same controller? The exact same methods with a switch for view type?
Your core controllers don't have to change, but that doesn't mean you can't have some extra ones solely to support you UI. For example, both of the Form examples you have can be unique to the Web API. Your entry URIs can certainly have links to those pages for both the machine and user interface, just don't expect the machine users to actually use them.
Also, if your machine clients are simply XML/JSON, then those representations don't need those links at all to the forms, since they'll not use them, and they don't "work" in JSON/XML anyway. You can manage that through Content negotiation.