ADO.NET vNext - feedback so far

re: ADO.NET vNext - feedback so far

Sam Gentile — Sat, 24 Jun 2006 17:00:24 GMT

Wow, I'm an "other" while everyone else gets a name-). I am going to be taking a deeper look at this soon and hope that I will find good things.

re: ADO.NET vNext - feedback so far

G.T. — Sat, 24 Jun 2006 19:04:15 GMT

Just a general comment, I have not seen the technology yet.

Never forget “and Microsoft always does” that as a developer, I would like the new framework to be more powerful than the previous one, easier to develop too, faster “Microsoft always have a problem with that one”, and compiler friendly “having SQL in a string is a typical example of ignoring the compiler ”

if the next ado .net is not fast (mapping == slower framework), or not easy to debug (mapping = runtime interpretation, like an sql statement in a string), mapping = one more layer now we need to worry about (more complex to develop for);

if all of this is true, I will stay with the current ADO.NET, or will look to someone else, like Oracle or IBM “incase they have a better ADO.NET” :-)

but first of all, should see the new technology first :-)

New and Notable 104

Sam Gentile — Sun, 25 Jun 2006 00:07:20 GMT

You know what? Owning a pool really sucks-). Oh, it’s great to go in but not a lot of fun spending most...

re: ADO.NET vNext - feedback so far

alexbarn — Sun, 25 Jun 2006 01:45:53 GMT

Hey Sam - look forward to it :-)

WinFS Updates...

Data — Fri, 30 Jun 2006 19:12:55 GMT

My friend Quentin Clark has posted a pair of updates to the WinFS project over on the team blog. A lot...

WinFS Updates...

Data — Sat, 01 Jul 2006 09:22:40 GMT

My friend Quentin Clark has posted a pair of updates to the WinFS project over on the team blog. A lot...

What about data + behavior ?

Adam — Thu, 06 Jul 2006 00:38:13 GMT

Great to see progress on data frameworks that means less time with SQL or CRUD methods.

But the assertion in the vNext papers that EDM somehow fixes the impedance mismatch problem seems like a real stretch.

In OO design, the mismatch is only a little bit about mapping CLR types to SQL types, or querying in C#, or even mapping language relationships to PK-FK relationships. The real mismatch is (1) effectively matching cyclic or heavily connected graphs that come from business domains to/from a relational DB without killing concurrency & performance, and (2) using a relational DB to preserve object private states while keeping the ability of objects to be defined exclusively by their *behavior*.

Real objects may have a property Getter that, depending on circumstances returns state, or computes new data, or talks to an external system, etc.

Is there a layer in the EDM architecture that deals with behaviors both on the traditional DB side (like constraints) and on the object side (like code that runs on a get or set that is _not_ pulling or pushing data in a persistent store)?

What happens to including methods in objects? If the EDM master model autogens the classes, how are methods woven in? As partial classes? aspects?

If the answer is that these classes are merely data structures or proxies, not "true" Objects (defined by behavior), then I'm not sure I see the big solution here...

ADO.NET vNext - feedback so far

ADO.NET team blog — Tue, 11 Jul 2006 20:33:40 GMT

(this post&nbsp;was originally posted here)

Since announcing our ADO.NET vNext plans at TechEd
...

Border Crossing Stats » Data Access blog : ADO.NET vNext - feedback so far

Border Crossing Stats » Data Access blog : ADO.NET vNext - feedback so far — Thu, 13 Mar 2008 10:41:27 GMT

PingBack from http://bordercrossingstatsblog.info/data-access-blog-adonet-vnext-feedback-so-far/