I have experience on MEAN STACK (mongo, express, angular and node). I am using AFNetworking for rest API. I am not able to manage MVC structure of my app. Actually I don't have the exact idea of what should be in model, controller and view folder of an iOS app. Any project template using AFNetworking or other rest API or any link would be appreciated.
Model-View-Controller (a.k.a MVC) is one of the most-used design pattern of all in Cocoa world. Here, controller handles the burden of saving, loading model objects as well as interaction with external resources such as network calls and/or core data.
However, in reality, this design approach can result in massive controller objects that makes it messy and less flexible. So, to encourage clean separation of role, a better design approach is used to move out the logic of networking or storage into a separate object.
There are couple of such design patterns that are built by respecting the principles of MVC. It really depends on your design approach.
For example, One of such pattern is, Model-View-Controller-Store (a.k.a MVCS), where you implement network/storage logic in "Store" Class (this is usually a singleton class). This also helps you to share common functionalities between different controllers.
I'd recommend you to read about design patterns in iOS. And, for your AFNetworking tut, you can refer this great tutorial.
Related
We are in the progress of building/migrating new features into our web application. We have a namespaced API (V1) that the mobile applications use to communicate with the app.
While we are in transition (we will launch the features for the web first), how can one differentiate between API requests and web requests, for purposes of bifurcating the logic in the shared model files? We need the models to stay the same for the mobile apps, but be different for the new big web-based features. Unfortunately code like
request.format
Isn't available in models.
Or is there a way to tell the API controllers to use different model files, and have separate models for some API vs. web app controllers?
I know that you should put as much code as possible within the model, however does this particular piece of code belong there?
It begs the question, because this seems to be 1) presentation oriented and 2) concern with the state/request.
It makes me believe that this code should actually reside within controllers.
API controllers to use different model files
Ofc, just use a different model...
You've provided little information about what you're trying to achieve, which makes things difficult.
However, this seems like some presentation oriented code based of a web state.
There for, add decorators to your application and do your conditional presentation there.
I am using 3rd party API to get and manipulate data used for my asp.net mvc application. Since I am beginner in MVC, from my standpoint I believe that use of models component of MVC pattern in such cases is not really needed. Only need to use models in this case would be if I would like to additionally manipulate data pulled from API.
Could someone please clarify if I am missing sometime in my theory.
I'm with you on your theory. It might seem a bit overkill to create a set of classes when retrieving data form a 3rd party application. In the beginning it may seem like a lot of unnecessary work.
However, my personal opinion is to always map classes in the MVC application. My reason for doing this is to keep as clear as possible separation of concern in my applications. If you need a similar application in the future or you are changing back-end for some reason, the MVC/front-end application will be as independent as possible.
It is also nice to keep a clear separation of concern if you are working with other developers and if the application will be used for an extended period of time. Also imagine if you would like to do some manipulation of the data, like you say in your own words.
To summarise, I think it is good practice to always keep a model class in your MVC application.
I have to set up a Asp.net demo using MVC 4 in a web application in order to help decision for a product that currently don't use this pattern. The model, view and controller should be simple, I just have two or three entities and a few pages.
I suppose I don't have to implement the whole infrastructure with services, repositories, etc. So how could I simplify the MVC components without loosing those advantages?
The MVC components aren't related to the data access strategy which you can use. To put together a quick demo (or a simple application) you can leave the data access in the same project but eventually split that out etc.
You can use something like AutoMapper to map from your entities to your view models if you want to put that level of abstraction in. You can also use EntityFramework contexts in the controllers to avoid additional levels of abstraction and only put in a simple interface/abstraction into one controller to show unit test ability.
Small examples of different patterns which could be used in the application is probably the way to go for the demo/presentation and not worry too much about putting them in all over the place. Remember the presentation and the delivery of information is as important, it not more, than the demo code itself.
In my current project I'm using backbone.js as a frontend technology. Ans I should note that I'm still on MVC3 but ready to move on;) Is it reasonable to create api area as data endpoint for my client part. Of course I can avoid it and leave just a plain controller in non-area, exterior part of my project. What is the best practice?
It is good practice to have a separate area for your client API that your backbone models interact with. Separation of concerns, readability and all that.
I would recommend using WebAPI for your API instead of standard MVC controllers though. It is easy to add via nuget, takes minimal config to set up, and it works well with Backbone's HTTP-Verb based approach to model CRUD operations.
If you are already planning on using WebAPI, then please ignore me! If you can't for whatever reason, then I would still say a separate area is a good approach.
I'm writting an application that has many Ajax widgets (Kendo-UI to be percise). It's starting to get messy to have all those Ajax responses without the standard controllers so I was starting to consider making each entities their own controller. If I'm taking the time to do this, I figured I might as well go foward and do those as WebAPIs since I was planning to do this in a not so close future, but hey, it would be done already...
So my question is: Is it a good practice to use an MVC application's own Web API as a Ajax Widget feeds or is there any reason to stick with standard Controllers?
I've seen some arguments about performance, but I don't think this applies to this situation. I believe it was more of a "Controller calling WebAPI" situation which has obvious performance hits. But since it's already a client side Ajax call, weither it goes into a standard MVC Controller or a WebAPI controller shouldn't change a thing, would it?
Edit
Additional information regarding the project:
I am using Entity Framework for the data access.
I have a repository pattern going on with UnitOfWork.
I am using proper a MVC structure (EF POCOs AutoMapped to DTO POCOs in the repository and fed into View Models by the controllers)
This is a MVC 4 project on .NET 4.0
There is a lot of database relationships (specially for the object I'm working with at the moment)
I don't know about "good practice", but it's certainly not "bad practice". I see no difference whether you do it in the app or a different one.
I think its a good thing but only if what you are doing in the API is kept as generic as possible to other applications and services can reuse the API.
Both the applications I have written and continue to maintain use pretty much the exact same stack as your app.
I have recently re-factored one of the applications to use the API for all the common things like lists that I'm binding to Kendo ComboBoxes etc. in my views. Its a fairly large application that re-uses a lot of the same lists such as states, priorities, complexities across various Entities and views so it makes sense to put those in the API.
I haven't gone as far as going the whole hog through. I draw the line with things like this:
public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
{
return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
}
That is very specific to how the Kendo Grid wants the data back. Nothing else I have connecting to this app will use this data in this format so I keep it in the controller.
In short... I use the API for common things within the same MVC app and things that I allow to be used by other applications or services, like Excel.