November 1, 2016 at 10:57 pm
Comments posted to this topic are about the item EzAdo - Part 2
Alan Hyneman
November 2, 2016 at 8:47 am
Thanks for the article. I'll need to go back to the first of the series.
November 3, 2016 at 1:03 am
SQL Server is expensive (compared to web servers and other software). Standard Edition costs >1K per core and Enterprise is about 6-7K/core. Why would you want to use it to generate JSON when it can be easily done on the client side?
November 3, 2016 at 7:58 am
Sql server is cheep compared to the cost of building software.
Compare writing a stored procedure vs
a) Write the query
b) Write the endpoint
c) Write the object at the endpoint
d) Create the command
e) Map the object to the command
f) Execute the command
g) Map the results to an object
h) Serialize the object to return it
In a cloud environment you are paying for processor regardless
I built a tool for the way we work, then I shared it. It's free and you can use it or not
Alan Hyneman
November 9, 2016 at 2:54 am
Alan
It's so unfortunate that people respond to your offering criticizing what you have done and made freely available. I have a simple response "If you don't like it, don't use it. It does what's needed and hopefully others can benefit either directly or indirectly.".
From my perspective, what you have produced appears to be 100% perfect for my use case. I'm very happy to follow convention/ coding standards. Especially when it means consistent, maintainable code, even more so if it means that I'm introducing patterns that result in code automation (in whatever layer).
My use case is simple. I need to produce a simple front end that communicates with the back end. I'm a database person, so I have the back end sewn up, for the front end I'm planning on using the code/ framework from webix.com, which supports calling REST services. All I need now is the component that supplies the REST service - enter ExAdo - perfect timing.
However I'm not a web developer, and the readme leaves me hanging. I have managed to run the tests, which all completed successfully. But when I set 'SampleREST' as the startup project and run it all I get is a browser message (403.14) about being unable to list the files. I've tried running the various appcmd statements in both the x32 and x64 program files folders for iisexpress.exe, including restarting the machine each time.
So I'm now stuck. Any advice on my next steps? I'll even do a write up for you to add to the end of the read me!
pcd
November 10, 2016 at 9:31 am
Can you email the full trace on the error you are receiving?
I'll be happy to help you through it.
Alan Hyneman
November 12, 2016 at 8:23 pm
Alan
Email sent. But for the benefit of others I eventually browsed through the CS code and managed to 'GET' some data. I now realise that there is no front end.
This URL returns a JSON string
http://localhost:58594/api/open/ORDER?ORDER_ID=2
NB This URL throws an exception in the code and eventually an 'index out of range exception' to the front end.
http://localhost:58594/api/open/ORDER?order_id=2
- the 'order_id' is lower case.
Again for N00b's 'postman' is 'Postman is the swiss army knife of API tools, allowing you to design, build, test, document and monitor your services, all in one place. Postman is available for Chrome, Mac OSX and Windows.'. It seems to be a way of calling REST API's and displaying the responses.
I'm sure it's much more than that, but for me that's enough at this moment.
pcd
November 12, 2016 at 10:16 pm
Casing is very important, and throughout the api the case depends on the object type. For JSON the mapping is camelCase, or in this case orderId vs ORDER_ID. For c# objects the mapping is ProperCase or OrderID. On the database side it is expected to be in UNDErSCORE_CASE. If you fallow that convention everything should just work.
Alan Hyneman
November 13, 2016 at 12:45 pm
I'm not saying that the whole idea is bad (or wrong). Just the step where SQL Server makes a JSON document on the server side could be easily moved to the client side (at least for simple flat "table looking" outputs), and it would save a lot of (expensive) CPU cycles on the SQL side. Reading column names/schema is not difficult, but savings are pretty huge.
November 13, 2016 at 7:33 pm
And for those who prefer that approach, and SQL Server version 2014 and lower where JSON is not supported, the framework supports building JSON in the service layer, plus you get the benefit of having the calling code prebuilt, and assignment of parameter values automated. The test project illustrates each of these.
Alan Hyneman
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply