It seems that Spine's Model.updateAttributes only updates attributes, and does not create new ones in case you supply any.
In my usecase, I have a controller that creates part of the attributes. Then through an Ajax request the server responds with the full object, and I want to update the model instance living in Spine with the additional variables.
For example, I have a model with attributes: name, date_created. Through the controller a user instantiates an object providing only the name. An Ajax request notifies the server which in turn responds with a name and a date_created. This date_created should then be added to the user's model.
Model.updateAttributes doesn't work, and I wouldn't be too fond of deleting the object and creating a new one - that just seems as too much overhead. I could provide default values for variables that are not set upon creation, but that also has a negative side. I guess what I'm looking for is a method that could be called Model.createOrUpdateAttributes. Can anybody recommend a way to achieve this? Thanks!
I might haven't fully understood your usecase, but I'll try to answer.
You need to declare whatever attributes a type of a model has with the configure class method. This declaration helps various model function to do their job later.
After you declare all the attributes you need, you can create model instances with any of the previously declared attributes.
You don't have to provide values for all the declared attributes.
After the ajax call returns, the date_created will be set on your model instance. Until this happens it will be just undefined.
If this solution still can't work for you, please describe why, and I'll gladly try to help.
Related
Just wondering really if there's a consensus on the 'right' way to do this, for MVVM, DDD, and other philosophies . . .
So I've got a login screen, represented by a ViewModel, LoginViewModel. It can take a name and password. It also takes in through dependency injection a LoginService, that implements the logic of taking the username and password, and retrieving the Employee object.
My question is what's the 'right' way to get this information to the next view model? Let's say it's AccountSettings, which needs to know about the logged in employee. How do we encapsulate that? I've got an AccountSettingsViewModel, but should it require
a) An instance of the LoginViewModel?
b) An instance of the LoginService, which keeps a reference to the logged in employee
c) A shared object or field on a global object, like App or something?
Thanks in advance!
Personally all my view models in DDD or otherwise are simple data containers, used to restrict the data that gets sent from the application to the UI/view. I might include some code in my view models that's specific to transforming data for that view. I also consider my view models to be coupled to my views (I only mention this because I've seen 2 teams put them in their own separate project/assembly away from the views!).
If I have anything copying data, or performing actions to get the data needed for the view model, this would live in either my domain model or my application layer, probably in a service. I wouldn't ever inject a service into a view model.
In my app, I have this scenario where I need to post an object to remoter server and get an object key back and then store the object locally. I have Core data and Restkit implemented in my app.
The object value are collected from user input. I couldn't figure out a great way to prepare the object before posting it to remote server. This object is an entity of type NSManagedObject, and I don't want to store it before I get the object id from server.
I came across this which suggested to use a transient object to handle this situation. But as discussed in that thread, this causes issue with code maintenance.
Is there a better way to handle this scenario? Thanks.
Make your core data model class adhere to the RKRequestSerializable protocol.
Then when the user input is validated, create an entity as normal and set it as the params value to the RKRequest, this will send your object as the HTTP body. Look inside RKParams.m for an example.
Also set the newly created entity as the targetObject for the RKObjectLoader. That way, when your web service returns the information (like the new unique ID), it will target the new object and save the new unique ID to this object without creating a duplicate.
Clear as mud?
PS: Oh and be careful mixing autogenerated core data classes with custom code! I recommend mogen to help you not lose code each time you make a change.
Let say we have an Order class and OrderManagerService class.
Order class: [some state and methods that act on the state]
Item[]
status
OrderManagerService class: [have no state. only following static methods]
createOrder
getOrder
Question: Let say we are using a relational DB in the back. Our goal is to update Order status. Well, the status need to get updated in the DB. My concern is where to put the updateStatus method.
Should I call OrderManagerService.getOrder then, call Order.updateStatus?
or create a new method as OrderManagerService.updateOrderStatus?
well, 1st option seems following encapsulation. But, personally I dont like it as we may end up calling DAO layer from entity objects [perhaps, that might be ok]. Wondering what would be a right design choice and why? any help is greatly appreciated.
Option 2 - create a new method as OrderManagerService.updateOrderStatus?
Why?
Your service layer should encapsulate the logical business unit of work and in your case the UOW is
get the order from DB
update the status of the object
persist the changes
and you would demarcate the updateOrderStatus(...) with a transaction. and the service is still stateless.
I think OrderManagerService should have an array of Order class items. This way you could iterate through each item and update the status there. Or if you are looking for accessing a single order item go directly to it via the Order class and update it there.
In either case with your current setup the updateStatus() should be in the Order class.
How about observer pattern?
updateStatus() would be in Order class, which would be observed by OrderManagerService class.
Each time you changed status (or anyting else) Manager would see it and do some actions if needed (for example update the status in the DB).
The manager could bind to Order when creating an instance and returning it in getOrder() method.
You could also implement some method to unbind Manager from an order if an instance of the order is destroyed (concern only in unmanaged languages).
Since the title of your question contains "using object-oriented design", I'd put the state transition logic in the Order itself because objects are supposed to encapsulate behavior in addition to data.
Having all behavior contained in Services can be likened to an Anemic Domain Model, which is up to you to decide if it's a bad thing or not - there's a lot of debate over that.
Why is there a separate OrderManagerService class? I'd bung all those methods into Order.
(That's probably not theoretically correct or gang-of-four-compliant design pattern but I dn't care because it would make more sense.)
i have a general design question.
we have a fairly big data model that represents an clinical object, the object itself has 200+ child attributes in the hierarchy.
and we have a SetObject operation, and a GetObject operation. my question is, best practice wise, would it make sense to use that single data model in both operations or different data model for each? Because the Get operation will return much more details than what's needed for Set.
an example of what i mean: the data model has say ProviderId, and ProviderName attributes, in the Get operation, both the ProviderId, and ProviderName would need to be returned. However, in the Set operation, only the ProviderId is needed, and ProviderName is ignored by the service since system has that information already. In this case, if the Get and Set operations use the same data model, the ProviderName is exposed even for Set operation, does that confuse the consuming developer?
It would say: it depends :-)
No seriously. How do you edit / work on the object? I assume your software is calling the WCF service to retrieve an object, using an ID or a search term or something.
So you get back the object with 200+ attributes. How do you work on it, how much of it do you typically change?
If you typically only change a handful of attributes - then maybe having a generic SetProperty method on the service that would take the object ID, a property name, and a new value, might make sense. But think about how this is going to work:
the server side code will get the ID for the object
it will load the object from the database
it will then set a single property to a new value
it will save the object back to the database
What if you update four properties? You'd go through 4 of those cycles. Or: you could extend the SetProperty method to include a dictionary of (property name, value) pairs.
So I guess it depends on how many of those 200 properties are you changing at any given time? If you change 10%, 20% of those properties - wouldn't it be easier to just pass back the whole, modified object?
This looks like a good candidate for using your clinical object as canonical model and providing a restful style service interface. You can then provide different views, or representations of your your data object with only the fields required based on the usage model. Your verbs (get, set) will become the http standard Get, Put.
There are a number of open source Rest frameworks that you can use to make this easier to get started. Restlet is one that I have used successfully.
I have set up a Core Data model where I have two objects, say Person and Address. A person has an address, and an address can belong to many people. I have modelled it in core data as such (so the double arrow points to Person, while the single arrow goes to Address)
I have then created two classes for those objects, and implemented some custom methods in those classes. In the Core Data model I have entered the names of the classes into them.
If I fetch an Address from Core Data directly, it gives me the actual concrete class and I can call my custom methods on it.
If on the other hand I fetch a Person and try to access the Address through Person (eg: person.address) I get back an NSManagedObject that is an address (eg: I can get to all the core data attributes I've set on it) but it doesn't respond to my custom methods, because it's of type NSManagedObject instead of Address. Is this a limitation of Core Data or am I doing something wrong? If it is a limitation are there any work arounds?
Did you create those classes using the modeller (Select an Entity, File > new file.., Managed Object Class, then select the Model Entity)?
A while ago I had a similar problem because I didn't create my managed object models using the Modeller. What I did to make sure everything was up and running was to copy and save my custom methods (and everything else I'd implemented) and start from scratch using the modeller. Then I was able to customize my model classes again and everything worked just fine.
I know this is not a complete answer but perhaps it can help you until someone explains exactly what is going on.
Cheers!
You probably just forgot to set the name of the class in the model when you created the entity - it defaults to NSManagedObject. Click on Person and Address in the modeller and check, on the far right side where the Entity properties are listed, that the Class field is filled in correctly with the name of the corresponding objective C class and isn't just the default NSManagedObject setting.
Your implementation file for the class probably hasn't been added to the Target that you are running.
(Get Info on the .m file -> Check the targets tab)
If your xcdatamodel has the Class set, if it can't find it at run time it will still work, you will just get NSManagedObject instances back instead. Which will actually work just fine, until you try to add another method to the class, as you have found.