EzAdo - Part 1

Question

Post reply

EzAdo - Part 1

Alan Hyneman

Mr or Mrs. 500

Points: 510
More actions
October 23, 2016 at 6:10 am

#314738

Comments posted to this topic are about the item EzAdo - Part 1
Alan Hyneman

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply

Iulian -207023 SSCertifiable Points: 7639 More actions · Answer 1

Excelent work, I was looking after such an exercise

thanks for sharing it.

Iulian

Alan Hyneman Mr or Mrs. 500 Points: 510 More actions · Answer 2

Thank You lulian.

I thought that since it made sense for me, and streamlined my code, that others might benefit.

Alan Hyneman

Iulian -207023 SSCertifiable Points: 7639 More actions · Answer 3

Is there something else other than FOR JSON PATH a stopper to use it with previous versions of SQL Server ?

If so then I would say that the _toJson converters can be overwritten and it should be used for other versions too.

T.a.

Iulian

Alan Hyneman Mr or Mrs. 500 Points: 510 More actions · Answer 4

It will work for other version, however the serialization would be limited to single entities. The full docs are included in the git project but basically you would call execute<objectType> and it would serialize the results for you. The test project shows the variations.

Also, after a serialization occurs the first time, the mappings are cached so that subsequent calls to the same procedure are no longer dynamically mapped. If you run the test project the execution times reflect the optimization.

This functionality is provided.

Alan Hyneman

vincent.grazapoli SSC Rookie Points: 48 More actions · Answer 5

This is awesome work, well thought out and really well done. Thanks for sharing.

One question though, I don't quite get the different Execute<> methods, Particularly the List<T> vs the <T>. I'm sure you have your reasons but I just can't seem to follow the logic.

Thanks again though, I can see us shaving 50-75% of our service layer redundancy.

Cheers!

Alan Hyneman Mr or Mrs. 500 Points: 510 More actions · Answer 6

Its really about the TEAM thing here. As an SQL developer I try to make things as easy as possible for the callers of routines, and the annotations help in that respect. In this case of

/*Single Result*/ annotation, it tells the service developer the procedure returns a single row, as a get by PK method.

Now the developer can do

var employee = Execute<Employee>();

vs

var employee = ExecuteList<Employee>().FirstOrDefault....

On the Sql side I'm being very clear on what I expect the service developer to do, and the service developer can now write clearer code as well.

Alan Hyneman

akljfhnlaflkj SSC Guru Points: 76202 More actions · Answer 7

akljfhnlaflkj

SSC Guru

Points: 76202

October 25, 2016 at 7:18 am

#1908594

Thanks for the good introduction.

Alan Hyneman Mr or Mrs. 500 Points: 510 More actions · Answer 8

No problem SS, by the way, the nugget package is done, be sure to follow the instructions in the read me.

Part 4 is in the publish queue.

Alan Hyneman

yogan.lee337 SSC Rookie Points: 33 More actions · Answer 9

Firstly, good job on taking on a task like this. We all know, something as simple as this, is not to be taken lightly. :smooooth:

However, why did you "re-create the wheel" when there are other libraries available (dapper, petapoco, etc)?

Wouldn't SQL converting the result set to JSON be somewhat slower than just returning the result set? Have you done any performance testing?

Alan Hyneman Mr or Mrs. 500 Points: 510 More actions · Answer 10

I built the tools for the way we work, Stack overflow built dapper for the way they work. Entity framework is out there and no one would dispute the usefulness of it for certain things.

As a developer you are free to choose your tools and hopefully you choose the tools that are most appropriate for the way you work. And I am providing another option, nothing more.

Primary advantages for EzAdo.

1) The procedures are prebuilt from queries around system objects, and all the parameter definitions are based off what the database (source of truth) knows.

2) You can load the parameters directly from an object, directly from Json, or set them by hand the flexibility is there. You can write objects if you want, but you don't really have to. That means you never miss a mapping.

3) If you have the REST stuff set up, as soon as you write the procedure the endpoint is exposed, there is nothing else to write and that is why we use it and the greatest benefit for us. Tuning an endpoint means tweaking a procedure.

Alan Hyneman