If I create models for request and response parameters for every http request in iOS project, it is easier for me to deal with models rather than dictionaries.
However, it will create too many models.
Is this a good approach or not?
And during the development, I found if there is only one model, for example, in an online shopping system, I only have one store model. But I use it in store module, cart model and order model. Actually in each module, the different attributes of the store model has been used. So this giant model always has some extra attributes for usage in each module.
Is this a good approach to manage the models in iOS projects? Or should I create CartStore model, OrderStore model?
To me, you should create models for different flows/modules to adapt Single Responsibility Principle.
From your shoes, the Store model should only contain the attributes of the store, if Cart or Order module need any further attributes then you should create another model.
Hope this helps.
The model approach will save a ton of your time when come back to fix or add on a new feature. Sure, They will take quite time but today Apple has already provide code codable/decodable protocol which will help you to handle parsing between JSON and Object Model. Also writing a unit test or even integration test it will be much easier for you.
Base on which data response of request, if have the same data structure should only create 1.
Ex: api get all stores and api get store with condition (distance, rating, ...) return storeModel, then we just using only 1 storeModel. And we have api get store detail (this api return more info than api get list stores above) just add more property in storeModel and using it again. So that with 3 apis, we only using storeModel
With your example, I think should create StoreModel, CartModel and OrderModel inherits from BaseModel. In this BaseModel, we'll have the all property which StoreModel, CartModel and OrderModel have, and in each children model, we will have only specific property.
Hope this help!
Related
I use back4app as my backend environment which is almost similar to Parse.
I would like to ask a few questions regarding organising data models relationships. Let me add a few words about my structure:
I have a User data model and a Project data model. Project can contain many User records. When I want to put a user to a project I wrap it to another data model called ProjectUser. I need this for separating levels when a User can be a part of entire system and when a User can be just a part of smaller things such as Project component I've described.
ProjectUser class has a User and Project as Relation (not sure do I need to use Pointer here):
So now looks like I can filter ProjectUser using Project key and get all needed users in appropriate project.
My question do I need to use such approach with filtering or do I need to add a new column to Project class with Array type and append this array every time I put new ProjectUser to a destination project? Can my Project class just contain array of another custom classes?
To summarise:
Do I need to use pointers instead of relations?
Is this better to create additional object with two custom classes in it (ProjectUser) or it's ok to use an array in Project data model to retrieve all Users or ProjectUsers.
UP
Faced the same question
have back4app as backend ad table to filter by related object (User).
I followed this examples http://framework.zend.com/manual/2.2/en/user-guide/database-and-models.html to create a model and a way to save it to a database.
But I don't like the idea of using the AlubumTable-class in my controller as I think this creates too much dependencies. I just want to add the save(), fetchAll(), etc. methods to my model so that I don't have to care about how to save my models inside my controller.
If I want to change the way my models get stored e.g. from a database to a REST-service I would have to rewrite every part of my controller where I get or store models instead of just changing the save() etc. methods in my model.
Are there any tutorials for my way or is this just a stupid idea? :)
The concern you have is actually OK, but you have to realize that the AlbumTable is nothing but a layer between your Controller and the Database. The AlbumTable actually is the one thing with the dependency, not the controller.
The Controller will always need some sort of "Service" or "Gateway" (which would be AlbumTable) to get access to the Data from the DB.
Also i do not understand what you mean by "i want to change the way my models get stored" - You should always store the MODEL into your Service. In the given example the Model is Album and the Service is AlbumTable. No matter where the data comes from - REST, RPC, "normal HTTP", you would always store the Album and not some ArrayData or whatnot. You'd rather try to implement a function inside your model like exchangeArray(), exchangeJson().
You may want to make your "problem" more clear to us...
I'm very new to AngularJS and MVVM in general and was looking for the best way to deal with displaying a model that also needs to display a couple of fields from child model objects on the web UI.
At the moment following basic tutorials my model object in my AngularJS controller reflects exactly my Rails model, and so I can't access fields from my child objects and just see their IDs from the foreign key columns in the database.
I'm wondering what the best convention is for dealing with this situation?
do I create a tableless model in Rails that contains only the fields needed by the presentation layer. Me defining what the presentation layer needs in Rails seems like it defeats the point of using MVVM.
do I create something on the AngularJS side that queries for the child objects using those exposed foreign key IDs? If so, how do I optimise it to avoid performing a request for each of my 50 objects in the table.
Yeah! You should define your api to contain all the data needed for a request. You don't need to create a tabless model for that.
If for example a fetch the json for a Post, Author and Comments json representation also should be there, or at least some part of it.
You might want to take a look at https://github.com/rails-api/active_model_serializers or https://github.com/nesquena/rabl
I'm starting to use Redis, and first thing my code is not too DRY, and was going to consolidate it in the application.rb and controller. Is this the best way to go, or should I make a new Class called Redis, and have all the logic in there?
My models are currently Customers, Orders, Products, and I'm using a lot of counters.
You will probably need a combination of new and existing model classes.
In many cases you can just drop the model used by the view directly into the datastore, which saves repetition. However, there will always be some places where the needs of the view and the datastore are different.
For example a property that appears as a list of values in the view may need to be stored as a separate set key rather than serialized with the other properties of the model.
This is mostly of a design pattern question. I have one type of model that I'm going to get the data to create them from multiple sources. So for example one record my be created from an API where another is created via screen scraping with Nokogiri.
My issue lies in how best to abstract out these different data sources. Right now I'm building lib classes that return the same hash which I then use to set the attributes of the model. But I'm wondering if this isn't more of a case to use STI. Or if there is some other way of doing this I'm just not thinking about.
I think your design decision would depend largely on what attributes need to be stored. From your description, it sounds like you have a model with multiple data sources, but which would be storing the same attributes regardless of the source. In that case STI seems like overkill. When you retrieve a row from the table, does it matter whether the source is the API or the screen scraper? If not, then you could just define separate methods for each data source and use the appropriate method in the controller.
#instance = MyModel.new(:datasource=>"API")`
I'd say don't worry about inheritance (or mixing in code from modules) unless you really need to. There are some gotchas -- STI is not fully supported by some gems/plugins, for example.