I'm recently doing a purchase order program using the MVC pattern in C# (not ASP.NET web app, just a desktop program). Now the problem is that in the UI there are lots of buttons that will link to another section, let's say from the order page I can click and go to the inventory page. Each section of course have their own set of MVC.
How can I connect the button to other controller while maintaining abstraction? That is each view does not have to understand how the other controller works, or what parameters it requires to work.
There are a couple of design possibilities that comes to mind but I have no idea which one is better / simpler:
The dirty way: just put the references to all the required controllers in one view, but this way reduce abstraction.
Shared view space: each button is a different view that has their own controller, but then I need to have view manager of some sort.
Routing: pretty much like ASP. NET RedirectToAction, make a custom router that use common type (like string) to determine which controller and which action to perform
Custom button for each action: for each controller and each action I make a button class just for it. Then I need a way for the view to supply the required parameters to each button.
Any suggestion on what should I do?
What i think that you should for the "shared view" i.e create on shared view containing all of that buttons and their calls if this is not working for you then you can create a saprate calls of WebAPI in their controller to get your date in return.
I decided to use a modification to my 4th option, a factory pattern that creates all my buttons. The factory is given the references to all the controllers and initializes all the buttons accordingly.
The view only need this factory during construction and ask for any of the button it can produce.
This way the view doesn't need to know anything about the controller during construction. The controller also doesn't need to know the view at all.
Thanks for everyone sharing their opinion.
Related
I am tasked with creating a Wizard-Like application that has many Views (UserControls) to load and unload dynamically based on a workflow. From any point in the work flow, I need to be able to jump to another View. In concept, the Wizard will know what View to load next based on the actions performed inside the current View... much like a state-machine.
I am looking for some guidance as to how to get started. This is a WPF desktop application and the current plan is to use Prism and Autofac. I can be swayed in this plan but I'd need to have some good reasoning behind it.
Specifically, does Autofac follow the concept of a ServiceLocator? If not, how do I identify and load the next View?
I expect that my MainWindow will contain one ContentControl and the Content property will be bound to an "ActiveState" property that will hold reference to a ModelView that will be mapped to a View. This ActiveState property will then be changed based on where the workflow sends me.
Thanks in advance for your help.
Specifically, does Autofac follow the concept of a ServiceLocator?
Not sure what you mean, but Autofac supports the CommonServiceLocator. You do not want to use the service locator anti-pattern, though, do you?
If not, how do I identify and load the next View?
Identifying should be the job of your statemachine. Loading it is accomplished through IRegionManager.RequestNavigate. As a side note: you don't need to go view-first, you can also navigate to a view model and have the view as a data template (just in case you're like me and prefer control template + data template over user control).
I have an ASP.NET application that was developed by "programmers". This application contains all things which you should not do:
Hardcoded settings
Copy/paste anywhere (code not re-used)
Make a lot of small SELECT requests to the DB for each row instead of doing JOIN
Model, view and controller in one function
Etc.
Now, my goal is not to throw everything away and start over, but I want to separate different aspects of the MVC of the application. I do not want to start a new MVC project, I would like to evolve the existing solution into something modular.
For the controller, there is no problem, I can create classes that will manage DB connections, send mails etc. On the other hand I do not know how to separate the view and the controller.
The problem that traditional ASP pages myPage.aspx have an associated file myPage.aspx.vb and in this vb file there are both view management part(page elements, like dropdowns) and also the Business part (controller) which is executed on the button click.
I thought about making a call to a myPageControl.vb class that will contain the business part from the file myPage.aspx.vb, which will call the Model (db, mail, other).
(View: myPage.aspx.vb) -> (Control: myPageControl.vb) -> (Model: Db.vb, Mail.vb)
The problem is: how should I do to modify the page content from the controller, for example change a list value or display a text on it. I have to make a call to the View (to the other direction) and pass by parameter the class MyPage (.asp.vb)
I have already tried to find an answer to my question, but I've found only answers taking about MVC projects.
Does anyone have any idea how I should do it?
Seperation of Concerns was one of the main problems with webforms, and one of the advantages of MVC. In my opinion the best you could probably do is seperate the business logic into classes like you are doing now so code could be reused throughout the application, but completely "seperating" everything may require rebuilding the application as an MVC app.
The only answer I've found to this is to have the controller send the "data to bind to" to the page as XML. then all the page has is its page_load of course, and then a method to receive the XML and update itself from it. You can use smart naming structures so that you can do reflection and autobind from the xml to page elements.
Then on an action, have the page generate an xml of all the elements on it and their values, and send that through a "ProcessAction" method that determines the correct controller and calls the right method on the controller.
But as suggested, doing it over as an MVC project probably makes the most sense if that's the pattern you are going for. What I suggested works, but it will be as much or more work than just starting from scratch with MVC. Besides, remember that "support" for web forms is disappearing soon. It's not in (and won't be in) .NetCore, so it's days are numbered.
Where is the best place in the project directory for the controllers for Shared partial views?
I have found similar question to: ASP.NET MVC: Correct place for Partial Views?
I can't decide if it is better to do something like /Controller/Shared/CONTROLLER_FOR_PARTIAL_VIEW or just create its separate folder like /Controller/CONTROLLER_FOR_PARTIAL_VIEW
The partial view is specifically for dropdownlistfor, and the model wont be used for anything other than to populate the dropdown. So if a site has many dropdown lists or just partial views in general, a shared folder seems to be the best option. If the preferred way it the Shared folder, do you use one controller for each partial view, or one controller for all partials? I appreciate any thoughts or feedback, thanks!
EDIT: To be clear, I m specifically asking about the directory for the CONTROLLERS not the VIEWS. Thanks!
In one sense, it doesn't matter. There is no true standard or convention for this, so you have the freedom to do it however it makes the most sense to you and your application.
Having it under something like Controllers/Shared could make sense, if there's enough of these that that is worthwhile and it adds value to keep them separate from regular controllers. However, in terms of a project, everything is essentially shared, so there's no true distinction here. Personally, simply having it named something distinctive is probably the best route. For example, I have a number of child actions in one of my projects that are used in various parts of my layout. As a result, I created a LayoutController to house these.
The one thing to keep in mind is that, if you're using standard routing, any controller will be available to the routing infrastructure, regardless of where it's located in your project tree. You'd have to pretty much just know how to get to it, but if you named your shared controller something like SharedController, then with standard routing, its actions would be available via /shared/action. For things like child actions, this is easily solved by using [ChildActionOnly]. By adding that attribute to your child action, it will be divorced from the routing infrastructure for URL requests. Internally, MVC will still be able to get to it for the purposes of rendering it for a view, though.
Projects I've been on it was at /Area/Controllers/SharedPartialController.cs and with that naming the view was at /Area/Views/SharedPartial/_MenuDropdown.cshtml
Hopefully you're using "areas" in your MVC project, in which case I would suggest doing one shared controller per Area.
I.e. /Order/Controllers/TabsPartialController.cs for one that relates to Order area, and then /User/Controllers/NavTabsPartialController.cs etc.
I'm working in a C# project and we are , in order to get some unity across the different parts of our UI, trying to use the MVC pattern. The client is windows form based and I'm trying to create a simple MVC pattern implementation.
It's been more challenging than expected, but I still have some questions regarding the MVC pattern. The problem comes mostly from the n-n relationships between its components: Here is what I've understood, but I'm not sure at all of it. Maybe someone can correct me?
Model: can be shared among different Views. 1-n relationship between Model-View
View: shows the state of the model. only one controller (can be shared among different views?). 1-1 relationship with the Model, 1-1 relationship with the controller
Controller: handles the user actions on the view and updates the model. One controller can be shared among different views, a controller interacts only with one model?
I'm not sure about the two last ones:
Can a view have several controller? Or can a view share a controller with another view? Or is it only a 1:1 relationship?
Can a controller handle several views? can it interact with several models?
Also, I take advantage of this question to ask another MVC related question. I've suppressed all the synchronous calls between the different members of the MVC, making use of the events and delegates. One last call is still synchronous and is actually the most important one: The call between the view and the controller is still synchronous, as I need to know rather the controller has been able to handle the user's action or not. This is very bad as it means that I could block the UI thread (hence the client itself) while the controller is processing or doing some work. How can I avoid this? I can make use of the callback but then how do i know to which event the callback comes from?
PS: I can't change the pattern at this stage, so please avoid answers of type "use MVP or MVVC, etc ;)
Thanks!
Model, View, and Controller are conceptual layers, not individual objects, so honestly it doesn't make a whole lot of sense to be thinking of them in terms of multiplicities. Nevertheless, I can try to approximate an answer for you.
A Controller returns a single result for a single action; that result may be an actual view or it may be something else. However, the Controller doesn't really actually have any interaction with the view; all it does is provide one or two pieces of information in its result: The name of the view that should be used and (optionally) the model used to populate. It's up to the View Engine to actually create and bind the view, which is a considerable departure from normal Smart Client UI logic.
A Controller may interact with several different pieces of the Model, or not interact with it at all in some cases; there is no rule for that side of the relationship. In an action result, a Controller has to give back either 0 or 1 instances of a "model", but this may not be the true Domain Model, it could be a View Model.
A View is generally bound to exactly one Model (or View Model), although in some cases a View might simply be content and therefore not bound to anything.
So, in the very crude UMLesque parlance:
Controller:Model = 0..* : 0..*
Controller:View = 0..* : 0..1 (request) or 0..* : 0..* (overall)
View:Model = 0..* : 0..1
This is all specific to ASP.NET MVC. If you were designing your own MVC implementation then obviously you could choose to implement it any way you like. Good luck implementing MVC in WinForms, though; Forms don't behave like Views at all, even patterns like MVP/MVVM are quite difficult (though not impossible, c.f. Microsoft's CAB/SCSF) until you move to WPF.
I´ve implemented the MVC pattern in C#. Don´t know very much about theory, or how it should be, or shouldn´t be. I just think that the pattern is the base idea, and then, you can use this idea in many different ways, depending on your own needs. I´ll tell you about my implementation, and hope it helps you.
**The Model**
Your description is pretty clear, so don´t have much more to said. Here is where I define my bussiness objects. I take advantage of this layer to include objects validation rules.
**The Controller**
In addition to handle the user actions and update the view, I have a Unit Of Work for each controller. I check that the objects in the view pass the validations (defined in the model layer) before commit changes in the Unit Of Work.
In my case, one controller can manage many models, and I like to have only one view in each controller.
Like a suggestion, I´d like to use my Framework with diferent UI, so I have an abstract implementation of Controller, and then I have specific controller implementations for different interfaces (WebForms, WinForms, ...).
**The Views**
In your case, we could call them, simply, the forms, the UI, ... I like to organize my desktop applications as if they were web applications, using tabs. One tab represents one controller, and so on, one view, and one or more models.
In conclussion, and in my case:
n models - 1 controller
1 controller - 1 view
--
n models - 1 view
You're probably over-thinking and over-formalizing it a bit.
Here's how I look at it:
Model: This is the actual thing that does real work.
Controller: This is the thing that sends inputs into the model, so it will do work.
View: This displays the results.
That's it. The easiest analogy to use is a console application - the app is the model, STDIN is the controller, and STDOUT is the view.
Extending that analogy, many GUI apps are built on top of command-line apps by attaching to STDIN/STDOUT. In that case, the things sending data to STDIN are the controller, the things taking data from STDOUT and putting on the window are the View, and the console app is still the model.
It's CS 101 again - input, processing, output. It's only trickier for a GUI app because the input and output are typically on the same window.
You (obviously) don't need to actually have a console app to do this - the separations can be done even in a single process. All the other weird wiring stuff that takes place is just whatever is needed to get this relationship between the parts to work. But the wiring isn't the important bit - the important bit is the separation of responsibilities and logical organization of the code.
So, whether 1 view must map to 1 controller, or any other orthognality issues are secondary. In fact, you should probably just do whatever your problem domain requires, but I'd (as typical) argue against over-eager generalization of code - IOW, don't mush things together that aren't really the same.
As a learning exercise, I want to migrate an existing flash application to ASP.NET MVC. It has around 20 forms, and although it's mostly linear, there is some degree of alternate flows based on user decisions or data returned.
Could anyone point me in the right direction of how a controller would handle this? I don't want my views to have to figure out where they go to next.
Update
I think I may not be understanding the correct way of building this. I saw each controller as taking care of a different section of the app, and having a main controller being responsible for workflow.
If this is not the approach I should be taking, what is the best way of doing this?
Update 2
Would Areas in ASP.NET MVC 2 take care of this sectioning of the app? I really don't like the idea of having too many actions in one controller...
In general:
Controllers are usually a collection of actions that deal with a logically coherent chunk of the application ( hence why you often see UserController / OrderController etc etc ).
MVC applications should be built using PRG ( post - redirect - get ) which means you will have 2 actions for each form, one that will display the form and the second, with the same name but decorated with [AcceptPost], that will process the form and redirect the user to the appropriate location based on the result.
The simplest way to learn how this works and migrate your app over is model each form as a simple dto with no logic, build a view for each form and 2 actions.
Once you have the logic working in the controller, you may want to migrate it out into some form of service that can be injected into the controller.
Specifically for your workflows:
Each workflow should probably have it's own controller. It may be useful to model them using some form of state pattern ( depending on the complexity of the workflow ), and providing a result from each state transition that your controller can translate into a redirect to the next step in the workflow.
When a form posts to a controller action it is the controller action to decide what to do with the posted results and which view to render next or redirect:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult HandleFormSubmission(FormCollection col)
{
// do something with posted data
// redirect to /someOtherController/someOtherAction
// which could show some other form
return RedirectToAction("someOtherAction", "someOtherController");
}
I was struggling with the same problem (using Windows Workflow Foundation with ASP.NET MVC) and I blogged about it here
Maybe you'll find it helpful, sorry for pushing my own link