My question is about the process of designing an ASP.NET MVC site and specifically about determining what controller classes and action Methods my site should have.
This is what I understand so far about the process of designing an ASP.NET MVC web site:
First, I should use a mock-up tool such as Balsamiq to create a
mock-up, so I know how my site should look. This gives me the views.
Second (or concurrently), I model the objects of my domain.
Given the views and the model, how do I proceed with the controller classes and their action Methods? A controller can call different views, so what's my "factoring" criteria?
So, my question is: Given the views and the model, how do I decide what controllers to have and which action methods each should contain?
Imho, a controller should reflect a specific functional area, dealing with a group of features related to each other. For example, you can have a controller dedicated to user management, where you create and edit users, manage user rights, user profiles, anything related to your users, another controller for product management, where you display available products according to user inputs, manage stocks, suppliers, and such...
With too much controller you end up redirecting all day long, with too few controller it's a mess to maintain.
Of course, when i say"this controller manages that group of features", i don't say "put all your business logic here". Controller's duty is to call the right business method(s) and to pass this data to the right view.
Related
For the first i want to sorry for my english. I'm learning domain driven design and trying to implement some concepts in an application i'm working on. My task is not so complex to fully implement DDD on all the levels but i really like it's principles and the core idea and try to use it.
Lets say app is selling books. So i have a Book entity and BooksCollection or BooksRepository. I'm working on frontend and that collection or updates to it is coming from server. And i want to represent it on BooksScreen in BooksList which consists of BookCard. Press on that card for the first calls something like selectBook which changes the selectedBookId in collection and for the second navigates user to BookDetails screen where the data of selected book is represented and the user can do some actions related to domain logic.
The first question is where do i put the loading state of that BooksCollection and according actions to change it ? Loading state is not a domain logic as i understand, it's not an entity status like "todo done" or something. But i need to show a loading indicator in the UI list when the collection updates, error for loading error and success respectively.
And the second is where do i put the the same loading state for single Book ?
I separate it cause for collection i may store that state in some application related class e.g. "BooksScreenState" or something with less stupid name. But what if i decide to show state for each specific card in the UI e.g. that specific card failed to load. Or i have a single User in app and his data can be loading, he can be authorized or not et cetera.
So i can summarize that to something like "how to connect domain and application logic to present a UI".
An interesting question. I don't usually think to apply DDD to the UI level because for the most part, the UI isn't full of business rules and also because I mostly use reactjs and UI frameworks are usually very prescriptive and don't allow much in the way of flexibility.
To answer your question though: If you did want to get a "loading" status in your UI (that's designed using DDD), it'd have to be attached to a "View" object or some representation of the "view"; because that fits the UL (ubiquitous language) better. Think of how you have described it in a little snippet of your question:
But what if i decide to show state for each specific card in the UI
That means your card is an object (entity or value object) that has a enumerable state of loading, loaded, error. You can queue on that object in your UI to display a desired representation of that field.
So, both your questions have essentially the same answer. Since you are loading the UI, your state is only relevant to UI objects and not entities that are in the domain model like "Books" that are represented in the backend. Even if you had a front-end representation of "Books" - like in javascript for example - having a loading state still makes more sense in the view object in the view layer.
Note that there's some simplification/flexibility to this answer because it's also valid for your design to have a View that's an aggregate that contains a Books. Those Book objects could have a "loading" state on them. All of this is still restricted to the UI layer though and such an aggregate and it's specific design will depend on the flexibility your UI-framework allows.
i am a rails programmer who is on to his 3rd project now (new of course).I am looking for an answer to a general question about Restful architecture. I am sure i am doing something that has a good established answer already.
In restful approach we expose resources but some times this approach feels a little Non user friendly. For example i can expose a product via a show method and then i have another resource called sales that i can expose via product/:id/sales show template to show all sales for a product. But i am taking the user through an extra click here. The ideal will be to show product and all its associated sales on one page itself. But that is a violation of the Restful rule.
I just wanted to ask that are these rules generally broken to make the site user friendly? Being a new comer i dont want to adopt ways that are non ideal so i thought i should ask this question.
Thanks in advance.
Adding in the sales for a particular product would not be breaking any constraints from the RESTful architecture. You have the product ID in the HTTP request so you can just also get the sales for that product. Your separation of concerns should not be affected and you don't need to store a state to get this information. Just extend the model that you return with the view.
It seems like you are more concerned with straying from the convention over configuration that Rails promotes. This extension means that your model will not correlate with only one table in your database, but that is fine. The conventions are meant to reduce the configuration work that you need to do, not restrict your functionality.
I have a model that has several columns I want to present to the interface to update as different pages. My question deals with what is the best rails-y way to organize your routes and controller actions.
For example, a User has a "Profile" and a "Billing Address". Both pages contain columns only from the User model, they are required and one-to-one, and small, so an additional model seems like unnecessary overhead.
It seems like I have to add a GET and a PUT for each different view I want to present, is that right? So instead of just edit/update, I'd need edit_profile/update_profile and edit_billing/update_billing, etc.
Even without a Profile model, I think you still can use ProfileController and views for profile like 'views/update.html.erb', and make it route as '/users/123/profile/'.
In my opinion, we don't need to mapping every view or controller to one model strictly. Rails is based on ROA, but here the "resource" can be more abstract.
I want to apply REST to my Rails 3 application.
I understand the basics but am still a NOOB and would like some help or advice if this is correct.
I have a USER model. However I have three kinds of User, as in they have different roles in the application.
When I create say the Celebrant I need to do other things in the create action that are different then the things I need to to for the Manager which is again different from what I need to do for the Participant.
So I was thinking of creating three resources.
1.Celebrant - new create only
2.Manager -new create only
3.Participant. -new create only
This way I can have the three REST NEW and CREATE actions that are different from each.
Is this the best way to go about this?
A couple of thoughts…
1. DRY
If Celebrant, Manager, and Participant all extend User, then it's best to have 1 controller. Most of the code will be the same between the 3 controllers otherwise.
2. Fat Models, Skinny Controllers
The controllers just pass parameters to models, so really you should only have to call 1 method on the model in the controller, like User.create. This makes it so your controllers don't perform any logic, so you don't need 3 separate controllers.
Check out the inherited_resources gem to pretty much remove all code from your controllers.
Doing it like this, you handle what happens before/after create in each of your User model subclasses.
3. Using a Role model instead of User subclasses
I ran into your exact problem before. I started with 3 user classes. But I quickly wanted to do more with the roles, add more, blur the lines, etc. By having 1 User model which has_many :roles (there's role plugins out there), you can handle all your custom logic in your save callbacks in the user model based on roles. Now your controller is lean, and you don't have to manage 3 classes.
Hope that helps.
I'm building a workflow for a Rails app in which a user logs into the system, and on the home page to the app a supervisor selects a student and a tutor who the student spent time. Then they submit the form. This should all happen on the app's home page. My problem is since it is not known when you go to that page who the specific student is, and thus who this form is for, it's not obvious to me how to setup the view and controller for this page.
Perhaps the form is for the lesson, but I've got a document (MongoDB) data model in which the lesson is embedded within the student document.
I could imagine a workflow where the user sees a list of students on the home page, and then clicks on the student to go to the model/controller for that specific student, and then enters the lesson's info there, but I'm trying to avoid unnecessary clicks and screens if possible.
Is my data model wrong? Is there a way to build this and keep my current data model? Is there a Rails pattern or helper that I should be aware of?
Thanks,
Bob.
When you build a workflow, you usually have one of your controllers behave as an orchestrator, and that controller sends the user to the right page.
Since you only want one form to send a user to 2 potential pages, you could post the form to a controller (a controller called "search" for example), and that controller decides weather to redirect the user to one of the two views, with the necessary parameters in the url (such as student_id, tutor_id or lesson_id).
And please work on your accept rate, you won't get many responses otherwise.