Last post Jan 22, 2017 07:03 PM by Go2Greece
Jan 22, 2017 02:15 PM|Go2Greece|LINK
In my Application, I have back end db tables that are not directly access by the connection string in the app. What I do is have a scripted function to update a database row in the schema used in the application save saves JSON based on the information in
the private tables.
So for example, I will create a Picture of the Day object from tables in another schema and pick a picture save it as JSON in the main tables this happens every 24 hours. It saves make query on a row that is going remain the same for 24 hours, when it is
severed thousands of time a day.
Anyway at the moment the deserialization is done directly in the DAL as it is retrieved and pass it up to the BLL as an object rather than a JSON string. The only place I need it to be an object is at the UI.
I am thinking of splitting the db and BLL/UI onto two servers, so I probally, it will be JSON from DB and then converted in to Object and then JSON again
In this kind of no search requirement of a RO object, is there anything wrong with passing the JSON all the way to the UI and just doing the deserialization there.
I could even pass the JSON string to a partital view and do the searilisaton there,
I got a few options, but not sure which one is best or why - any feedback, recommendations or best practiced would be great - thanks in advance
Jan 22, 2017 04:41 PM|mgebhard|LINK
Deserializing means converting from a string to an object.
The only place I need it to be an object is at the UI.
If the server side code does not required an object then render the JSON directly to the response HTML (View).
Jan 22, 2017 07:03 PM|Go2Greece|LINK
Thank you for your answer,
So it is a string everywhere else except the UI - Thankyou this is what I was hoping to be the answer - this means I can move the JSON serialize and deserialize out of the DAL, my first attempt was wrong