I'm still not used to the MVCS design pattern. I read in a book that if I was planning to create an app that gets information from an external source, it's better to use MVCS instead of MVC.
I'm currently working on an ios app that gets information from multiple external sources. For example, I'll be fetching info about the weather from a web service, driving directions/time probably from Google, and data from our database via a web service as well.
My question is, do I need to create more than one store object in this situation? Like create a store object for each of the external sources? Or do I just create one for all of them?
I think it really depends on your design approach as you can have dozens of different design approaches which all respect the MVC principles and that therefore are all correct.
Personally I would suggest to try to decompose the problem as much as you can in smaller problems, in order to get the most from the flexibility that a objected oriented environment gives you.
In this case, for instance, you could think about having an abstract store class in which you implement the common functionalities you need to have and then subclassing it for each different web service you need to use and implementing the other functionalities related to that specific service. It's just an idea! I hope this helps.
Related
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.
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.
So I'm building a Github based application with octokit and the rails api, I have the basic idea of what I want to do, but I'm not too sure where to do it. Is it better to manipulate fetched data in the model or in the controller, any help would be appreciated! Thanks ya'll.
I've found the best way to figure out a question like that is imagine that you were writing an statless, UI less API for the application that was going to be called by various different clients, like a web service.
If the "manipulation" has to do with presentation in some UI of the objects represented by the models, then that sounds like controller. If its a "behavioral" feature of the objects themselves, or the type of manipulation that would be useful no matter what the presentation (for example a list of objects in some useful order based on the model properties) than I like to put that kind of thing in the model.
Hope that is somewhat helpful.
I'm new to Grails and web development. I started doing a project on Schedule management website stuff. I came across the Service concept that is provided by Grails. I understood the concept, but still I have confusion on when to use services.
For example, I need to implement a search module, where the manager can search for a user to find his schedules. In this case it will be good to implement it as a controller or as a service?
So,
When and where should I use Service?
To add to Grooveek's answer;
It is also nice to use Services to keep your Controllers nice and clean.
So Views just render data to the screen, Domain objects store state, Controllers route the user around the application, and Services perform the work.
I don't have enough reputation to comment on an answer or vote up so I have to provide an answer that really should be a comment. Anyways...
+1 on #tim_yates answer. Gotta love thin controllers. 2 things that I would add to the description of a controller:
Would be to translate parameters from the browser before hitting a service (e.g. Date, number, etc.)
Would be to translate data returned from services into something consumable for the views.
For me, ideally, services would never deal with translating a String parameter to it's inherent type. Or deal with building a model to be displayed on a view.
What and where I should use Service?
When you want your controller do to something that may be reused by other controllers
In our application we're doing a functional separation of service. We have a CorePersistanceService, which provides method to create, delete, update and manipulate Core Domain Classes (core for us).
I think persistance services are a good way to reuse GORM code throughout Grails code. You can create method in domain classes, but I don't like that, it's way less maintanable I think
We have a PDFService class for our PDF creation, a SolrService which connect to Solr, a Statisticservice that gather all our methods which collects statictics on our datas
Services in Grails are a manner to gather methods around a particular functional theme, in order to give possibility to reuse them in controllers (I forgot to mention our SecurityService, which is a pretty good Cross-Applications Example)
I have an MVC app I'm writing. There will be the need for multiple instances of the same page to be open, each accessing different records from a database, these record objects will also need to be passed through a flow of pages, before finally being updated.
What's the best, and most correct, way of acheiving this - should/can I create a custom model binder that links to an object via it's unique ID and then create each record-object in the session, updating them as I go through each one's page flow and then finally calling the update method? Or is there a better way of dealing with this?
Cheers
MH
Technically, that would be possible, but I don't think it is advisable. When you look at the signature of IModelBinder, you will have to jump through some hoops related to the ControllerContext if you want to be able to access the rest of your application's context (such as how to dehydrate objects based on IDs).
It's possible, but so clunky that you should consider whether it's the right approach. In my opinion, a ModelBinder's responsibility is to map HTTP request data to strongly typed objects. Nothing more and nothing less - it is strictly a mapper, and trying to make it do more would be breaking the Single Responsibility Principle.
It sounds to me like you need an Application Controller - basically, a class that orchestrates the Views and the state of the underlying Model. You can read more about the Application Controller design pattern in Patterns of Enterprise Application Architecture.
Since a web application is inherently stateless, you will need a place to store the intermediate state of the application. Whether you use sessions or a custom durable store to do that depends on the application's requirements and the general complexity of the intermediate data.