I am part of a development team implementing a large application. There are several layers to the application, and we'd like to make the organization of files as easy to maintain as possible, but also follow best practice.
Here is an example of how this is laid out based on MVC convention.
UIProject
- Controllers
- HomeController.cs
- ErrorController.cs
- PersonalInfoController.cs
- BaseController.cs
...
- Views
- Home
- Index.aspx
- Home1.aspx
- Home2.aspx
- PersonalInfo
- Step1.aspx
- Step2.aspx
- Step3.aspx
...
- Shared
Site.Master
Error.aspx
...
However, we have realized that the functionality of PersonalInfo has grown, and really should be broken down into multiple controllers. We'd like to organize them in a subfolder of the Controllers folder. Something like this:
Controllers
- HomeController.cs
- ErrorController.cs
- BaseController.cs
- PersonalInfo
- Step1Controller.cs
- Step2Controller.cs
- Step3Controller.cs
This can be done, each of these controllers would be within a PersonalInfo namespace. A Route can be mapped using the namespace argument.
The real issue comes in with getting MVC to find the associated view. I have found two ways to get around this. One, by clanmonroe.com, handles this by inheriting from a base controller that specifies a hardcoded viewpath. Another, by Stephen Walther, more simply suggests providing the view path in the call to the view.
Both of these methods seem to work, and I'm more partial to the first method. However, they have drawbacks. Mainly, that we now no longer force the convention. That is, Step1Controller.cs could have an Index Action, but the View could be named foo.aspx.
Ideally, we'd like a way to implement an organized approach using MVC natively, w/o quirky workarounds. Is there an established best practice for situations like this, or at least a good recommendation?
This sounds (more or less) like the new areas feature in ASP.NET MVC. According to ScottGu:
Areas provide a means of grouping controllers and views to allow building subsections of a large application in relative isolation to other sections. Each area can be implemented as a separate ASP.NET MVC project which can then be referenced by the main application. This helps manage the complexity when building a large application and facilitates multiple teams working together on a single application together.
It's not implemented exactly as you describe it, and rather than a sub folder within Controllers, it expects you to split your areas into seperate projects. Each area can then contain both controllers and views.
Related
In an effort to push our development toward a resource-based, CRUD pattern, I'm using RESTful controllers in Laravel. However, I'm running into a need for non-standard methods in these controllers. I often need to add methods to the controllers to handle actions which don't fall into the CRUD pattern.
Does this mean I should abandon the CRUD+REST pattern altogether and pick it back up when a future project can fit into the CREATE/READ/UPDATE/DESTROY pattern? Or does the CRUD+REST pattern still assume that a project will need some non-standard methods in many instances? If so, is there a preferred way to implement them?
For example:
-- Presenting a list view of a given object in the system. Say, a list of users or list of posts.
-- OR Attaching, say, a maintenance script or command to a button.
Neither of these instances seem to correlate directly to a CRUD method.
Lately I seem to be struggling to organize all of the different Classes/Objects I am working with. In my case, I work for a company that has 3 core products that are different - but share some core functionality. So, they will also share classes. To muddy the waters some more, I am writing ASP.NET MVC app - which has an implicit location for Classes (the Model folder).
So - here is how we are currently doing things. I am going to refer to the product as NewProduct. xxx is the company name:
xxx.Core - Classes used in all products. These could be helper functions, actual classes with logic, etc.
xxx.NewProduct.Web - The MVC Web App for the NewProduct. The Models folder is empty.
xxx.NewProduct.WindowsService - A Windows service - part of the NewProduct.
xxx.NewProduct.Models - Basically, this replaces the Models folder in the MVC Web app. They are in their own project so that the DomainLogic can fill them and pass them back to the MVC App.
xxx.NewProduct.Objects - Classes with logic (not just Skeletons like Models) that are shared between Web and WindowsService.
xxx.NewProduct.DataAccess - This is the DAL, not all that important to my question here.
xxx.NewProduct.DomainLogic - This is the business logic layer (makes calls into DAL).
Also, if we are to write some other app in the future (Mobile, Desktop, etc) these can be reused by it as well.
My main problem is when I am trying to decide where to put an object, there are times where I am not sure where to put it. Is this normal? Do others have this problem? Any suggestions?
of course it's normal! there is no one right way to divide your modules. but don't spend too much time on this. we are living in IDEs age - you can always refactor. for me, the most important is readability. when other programmers from your team look for the some class/functionality they should not be surprised - that's all. for example i have no idea what can i find in module named Objects (but i don't know .net nor specific of your application).
In my current MVC2 project I implement my MVC by creating a "model" class that gathers data from the database and runs it through business logic, etc. Then I have a "Controller" that gets the processed data from the model and sets the values in a "ViewData" class. This "ViewData" class is a class of getters and setters. This ViewData is then passed to the view in the Controller like this : return View(myViewData);. Finally, in the View, I bring in the data stored in the ViewData by putting this line at the top of my aspx file.
<%# Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<Core.UI.Web.ViewData.MyViewData>" %>
So, is this the way MVC3 is done? I have a guy on my dev team that is suggesting that the model should be sent, via the Controller, directly to the view like this: return View(myModel);. His reasoning is that this is MVC not M.V.VM.C.
I understand that ViewBag can be used but that just seems like a quick data container.
So, in other words. ViewData or no ViewData?
Thank you,
Aaron
There are certain situations where you might want a view model: to combine data from multiple models/sources, or for specific validation scenarios, etc., but, it's perfectly acceptable to have your view take a model without an intermediary view model, especially if the view model is just a class of getters and setters with no other functionality.
If you're not concerned about exposing methods/properties from your domain model (or if it doesn't apply), I would just pass the model straight to the controller.
In your instance ViewData is just a model - it is a ViewModel and is perfectly fine, and actually the recommended approach in general to use. The reason being you dont want for instance, a primary key from a customer model rendered in the case of a "create customer" function - as a customer id doesnt yet exist. However for editing a customer record, you surely need a key. So - if you use viewmodels in some cases and not in others, not you are inconsistent in your project.
'yes' you can - but I prefer consistency and using a view model gives you the consistency.
You can also use the model - and thats normally how the MVC demos are setup, but unfortunately like most demos, they don't give you what is architectually best, but what is best in whipping together a 5 minute application.
As other have said, although you can get by passing Models to your views, sooner rather than later you'll find yourself wanting to add properties for display purposes only that don't quite belong to the model (e.g. values depending on the current session rather than the model itself.) When you hit that point and it's usually pretty soon you'll be glad you used viewModels.
Technically speaking ASP.NET MVC is not even using MVC but rather Model2. Dino Esposito has a good article about this. Furthermore, on his book Microsoft .NET: Architecting Applications for the Enterprise he even goes as far as saying:
"It is a sharp and bold statement, but we have to make it: today classic MVC is gone. However, some of its variations are healthy and thrive. They are Model2 for the Web and MVP for both Web and Windows. In turn, and only more recently, MVP has undergone a facelift. In July 2006, Martin Fowler proposed to retire MVP entirely and replace it with two variations Passive View (PV) and Supervising Controller (SVC). “
I wrote a review of this chapter on my blog.
I have read Apple's MVC article and am confused about various things. Firstly Apple uses a combination of the View and the Controller in almost all its sample applications which is fine and I like it but they contradict themselves in this article because they said that View's should not rely on Controllers etc.
My main question is does anyone have a link to one of Apple's sample iOS projects which is a good example of the MVC pattern - with data retrieval etc because I don't fully understand the Model part of the pattern.
I don't understand the difference between a 'domain object' and a model object. For example if I wanted to retrieve a list of orders this would happen in a model class Orders. Would I then have another class Order which has properties such as OrderDate, OrderNumber etc or how would this work?
This sample code demonstrates a multi-stage approach to loading and displaying a UITableView. I think it's really interesting to dive in. It will show MVC in the works.
Here’s how the Model-View-Controller (also known as MVC) pattern maps to the main parts of your App:
Model → Data
View → User Interface
Controller → Core Logic
this explain fully with sample code
http://www.hollance.com/2011/04/making-your-classes-talk-to-each-other-part-1/
I believe that the following code will help you understand how to work with MVC in iOS application because its description says:
"MVCNetworking is a sample that shows how to create a network
application using the Model-View-Controller design pattern.
Specifically, it displays a photo gallery by getting the gallery's XML
description, thumbnails and photos from a web server, and uses Core
Data to cache this information locally."
http://developer.apple.com/library/ios/#samplecode/MVCNetworking/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010443
The model is the brain of the application. It does the
calculations and creates a virtual world for itself that can live
without the views and controllers. In other words, think of a model
as a virtual copy of your application, without a face!
A view is the window through which your users interact with your
application. It displays what’s inside the model most of the time,
but in addition to that, it accepts users’ interactions. Any
interaction between the user and your application is sent to a view,
which then can be captured by a view controller and sent to the
model.
Controllers in iOS programming usually refer to view controllers. Think of view controllers as a bridge between the model and your
views. They interpret what is happening on one side (what the user
does on the view side, or the information provided by the model) and
use that information to alter the other side as needed.
This is by far the best, yet simple explanation I've come across(taken from RayWenderlich)
"The idea behind MVC is that
- VIEWS should only care about how they are presented HOW THEY ARE PRESENTED,
- MODELS should only care about their DATA, - and CONTROLLERS should work to MARRY the two WITHOUT necessarily knowing too much about their internal structure."
I'm starting a new project which in simple terms will have a UI layer based on asp.net mvc 2, a business layer and a data access layer. Simple 3-tier design.
The UI layer though will be customized for the client, e.g. menus along the top, or down the left or maybe different static pages, etc.
All the core features will be the same across the multiple clients but some clients may have more or less features available to them.
I'm thinking of using Areas in one single asp.net mvc project to separate the clients. So as I add clients I will add areas - is this a good approach? If I follow this approach can I share controllers? but have the controller route to the correct view within the area?
Also if I deploy my site to mynewsite.com - each area is going to be accessible at mynewsite.com/area1, mynewsite.com/area2 and so on. But if a client would like their own domain, what is the best way of achieving this? so that www.clientdomain.com -> mynewsite.com/area1 and clientdomain.com/products/list is the same as mynewsite.com/area1/products/list - would I have to handle this through the HTTP Url Routing on the server?
Hopefully I've explained my situation ok! Many thanks for any feedback.
Just for information - I decided against using areas in the end and I have simple client configuration component with custom view engine that I put together to swap out the views per client (using domain name and/or when the user logs in). The views are currently held in client specific folders and I only put the views I need to change for a client into those folders, if the view engine cannot find the view in the client specific folder it will revert back to the default views, which is pretty much the normal case as 90% of the client specific changes are done with CSS.