Hi I am working with Cloud based application and I am researching on various ways of Mapping Electronic Data Interchange. In my scenario I have to map two external application attributes suppose:
Application 1 :
firstName ,
lastName
Application 2 :
fname ,
lname
The one way i am doing is mapping the attributes in the XML like this :
<App>
<firstName>fname</firstName>
<lastName>lname<lastName>
</App>
Here I am assigning the attributes of first application with the attributes of second application.
I am looking for the optimize and best practises for mapping the attributes of two application.
I am also looking for the convenient way of storing the mapping data in to XML, JSON which one is more convenient and flexible and take less time in conversion programming.
Related
I'm investigating using Breeze for client side caching and querying. Unfortunately the existing web service returns (JSON) objects that for a given type may have variable number and type of fields. They will all have a unique id and a few base fields, but for example a Person may have name, age and address say, and another Person may have name, birthdate and favoriteColor.
What each Person has is described by metadata sent embedded into each object (so each Person also has a metadata field).
Querying is obviously problematic here but assume for now that we will not be querying on any field that is not on all items of a given type.
We are using AngularJS too, in case that is relevant.
My question is, how would one handle this situation using Breeze? Would we be better off just using a simple object cache and "querying" simply by iterating over the cache with a predicate function?
Perhaps you should take a look on Jhon Papa's pluralsight video lecture for querying using client cache on pluralsight , which is a complete demonstration of breeze and angularJs. Also you can refer this
I've been looking at the different approaches to solving the mass assignment issues with MVC as well as doing things the right way.
So far, the 2 approaches which I think are the best are below: (I have also looked at AutoMapper)
1: Value Injecter - This seems to do the job pretty well, but also relies on a third party library
2: Using the UpdateModel method and bind to a View Model interface which exposes a subset of the required properties in your domain model. http://www.codethinked.com/easy-and-safe-model-binding-in-aspnet-mvc
Before I jump in and code my whole application (without spending a week on each to find out which one I actually like) using one of the above practices, does anybody have real world experience of using these 2 methods and which one you would recommend?
in simple scenarios where you have only text fields matching strings/int properties anything will do just as well.
but when you have properties on the viewmodel that match objects in the model (FK in the DB) it gets a bit more complex, you might need to pull data from the DB for some individual props and map some property of that object to the ViewModel, stuff like that.
prodinner asp.net mvc demo application uses valueinjecter in Mapper classes, there's a pdf where this approach is explained, you can download it here: http://prodinner.codeplex.com/
General consensus from all the reading I've done on this topic is that if you're going from a Entity or Domain Model (from your database) to a View Model to show on the form feel free to use automation tools like AutoMapper or whatever your preferred tool is to automate it.
If you are however going from a Input or Form Model (the object populated via the automatic model binding) back into to your Entity or Domain Model, do not automate this. It's a slippery slope to navigate correctly and can result in your automation tool mapping over fields that were not intended/permitted. Everything I've read about this (and various implementations myself) suggest the best practice is to do this manually/explicitly. It's pretty straight forward and object initializers can make it very easy to read.
var person = new Person()
{
PersonId = model.PersonId,
FirstName = model.FirstName,
LastName= model.LastName
}
personService.UpdatePerson(person);
Something along that line.
I'm working to import and export data into Core Data from a web API.
The web API that i'm interfacing with doesn't have consistent naming with itself, and certainly doesn't match the naming conventions that i'd use for attributes in my core data model. (I don't have control over changing the API conventions).
To illustrate the issue, in one api call the data for a contact might look something like this :
"rows": [
{
"name": "Bob",
"group": "Testing Group A",
"email_address" : "bob#fakedata.com"
}
]
And in another different call that still returns contacts it might look something like this :
"rows": [
{
"Name": "Bob",
"group_name": "Testing Group A",
"Email" : "bob#fakedata.com"
}
]
Notice the small differences in the key naming? In the past, i've resolved issues like this by having a "mapping" for each API call. The mapping is just an NSDictionary that has the key's of the core data names I use, and the values of the API server keys.
So resolving each of these two calls would require each to have an NSDictionary like the following
dict = #{ #"name" : #"name", #"group" : #"group", #"email" : #"email_address" };
dict = #{ #"name" : #"Name", #"group" : #"group_name", #"email" : #"Email" };
This works pretty well, and it's certainly one path to solve this problem, but having these mappings in every API call isn't very elegant, and certainly is poor design for code maintainability.
So the real question here is : does anyone have a better solution for managing the mapping of web api's to Core Data? Obviously having a well written web API is the ideal solution, but even mapping well written API's can have minor differences (For example, core data requires attributes to begin with a lowercase letter).
My proposed solution is to add the mappings into the core data attribute under the "User Info" (attached image below to see example), but i have zero experience using this feature of attributes, and I don't know if there is a way better option that i've overlooked. Thanks for any help.
Additional Notes : Yes, i've used Restkit extensively, and it does have convenient mappings (similar to how I've explained using an NSDictionary above). But for this project, i'm eliminating dependency on such a framework that I don't have control over, and don't completely understand. I'm pulling this data in with a simple NSURLConnection.
update
If you go down this route (which has been very nice btw, the accepted answer helped a lot). I recommend not using the key word "map" simply because it's not the default. Use "key" instead because this doesn't require making two edits to the user info field. For my particular project there are many mappings and this has been annoying. Too late to change now, but learn from my mistake.
Wow, that is one screwed up web API.
Your suggested approach is more or less how I'd deal with it. But instead of having multiple mapX keys, I'd use a single map key whose value was a comma-separated list of mappings. In this case, the key map would have a value of Company,Company_Name,company. That way you read one known key instead of repeatedly testing to see if the next one exists. You can easily convert the comma-delimited list to an array by using NSString's componentsSeparatedByString: method.
A different approach would be to put all this in a property list that you can read at run time. That would be effective but I prefer keeping all of the information in one place, and the user info dictionary is ideal.
As an aside, for what it's worth, Core Data does not require that attribute names begin with a lower case letter. However, Xcode's data model editor does enforce that restriction-- forcing you to follow a guideline that you might well have cause to violate. If you're so inclined, you can edit the model file by hand and change attribute names to start with upper case letters. The file is XML, and if the tool compatibility setting is Xcode 4.0 or higher it's very easy to read. Once you do this you can even use Xcode's built-in class generation with those attributes.
First of all i shall clarify that i am using Database First Approach using WEB API for a REST service. (Generally Developing The old fashioned way , and using the EF only for some features)
I have a model corresponding to a Database table let's say
Model Client
--id
--owns
--address
--VAT number
--Credit card number
Model Session
--id
--clientID (FK)
--date
Now there are several times when i want to return only part of a model to the client, and some times combination of model data
{ClientName , Owns , LastSessionDate ) Or several other combinations
Only tactic that comes in mind is creating different models for each response (that comes with duplicate validation declarations etc).
Or when the response is only part of a model(Not a combination) Just nullify the fields i don't want and tell the parser not to render null fields.
Is this the correct way or am i misconceiving something?
Typically I have a different model class for each response (or screen/view in a web app). Sometimes you can re-use these view models, but it's usually more trouble than it's worth.
I have a Web API project with models that look like this:
public class Account{
string FirstName{get;set;}
string LastName{get;set;}
}
I would like the JSON response to use a different format and casing for the properties, like this:
first_name
last_name
Is there a way to perform this globally through some sort of json formatter, or is it best to create separate ViewModel classes with appropriate casing?
You should create separate viewmodel classes for a number of reasons.
It is best to use separate viewmodel classes so that you do not overexpose your model. In the case where you use an entity class with 10 fields as a view model, and you only want to expose 5 of them, a malicious user may post the extra data with a querystring and the automatic bind may fuse that in without you realizing it.
In your example case, you may want to use entirely different names for the fields. This is a perfect candidate for making a custom viewmodel for your entity class.
Separating these concerns will help your application be more re-usable in the future, and easier to test / debug in the present. If you find yourself in the situation where there are too many view models, consider factoring out these different controllers, views, and models, into separate areas ( blog on areas ).
As a side note, if you want to format the JSON it may be easier to do it after the fact in javascript rather than before hand because usually editing the JSON serializer class is a large endeavor. You could write a script which went through and automatically converted camel case to _ separated lower case. A downside to doing that would be that it could have unintended affects in the future if you did not expect the functionality to perform like that.