I wish an SQL Server version...
-
Which capable to retrieve and store data as CLR objects. :)
-
Which capable to retrieve and store data as CLR objects. :)
Serialize/deserialize?
-
Serialize/deserialize?
No, that would be a wrong idea right? What I think that the SQL Sever will convert data from and into objects with the help of some mapping files(same idea of ORM). So that I can completely replace my DAL.
-
Which capable to retrieve and store data as CLR objects. :)
You could embed a linq2sql assembly in the server.
xacc.ide
IronScheme - 1.0 RC 1 - out now!
((λ (x) `(,x ',x)) '(λ (x) `(,x ',x))) The Scheme Programming Language – Fourth Edition -
You could embed a linq2sql assembly in the server.
xacc.ide
IronScheme - 1.0 RC 1 - out now!
((λ (x) `(,x ',x)) '(λ (x) `(,x ',x))) The Scheme Programming Language – Fourth EditionThen its maintenance would be a headache. Isn't it? A native support can free me from that.
-
Which capable to retrieve and store data as CLR objects. :)
Isn't that effectively what the ado.net entity framework does?
Simon
-
Isn't that effectively what the ado.net entity framework does?
Simon
Don't you think this is pretty simple than entity framework?
-
Don't you think this is pretty simple than entity framework?
No. Storing CLR objects is a complex business. What would do you do with references? What do you do with lists/collections of references? What do you do with pointers? What about when you have circular references (like objects that have pointers to their parent objects). What about sub objects that are shared by multiple parents, do you store them twice or just once? What about Structs, do you handle them differently? All of this has to be configured on a case by case basis, which is essentially what the EF does. It allows you to define exactly what will be stored, how and where. Currently the objects used by the EF have to have all sorts of tags and interfaces on them. From .net 4.0, the EF will support "Plain Old CLR Objects" (POCO) which means you can use the EF with any existing object without modifying it, so effectively will be what you are asking for.
Simon
-
No. Storing CLR objects is a complex business. What would do you do with references? What do you do with lists/collections of references? What do you do with pointers? What about when you have circular references (like objects that have pointers to their parent objects). What about sub objects that are shared by multiple parents, do you store them twice or just once? What about Structs, do you handle them differently? All of this has to be configured on a case by case basis, which is essentially what the EF does. It allows you to define exactly what will be stored, how and where. Currently the objects used by the EF have to have all sorts of tags and interfaces on them. From .net 4.0, the EF will support "Plain Old CLR Objects" (POCO) which means you can use the EF with any existing object without modifying it, so effectively will be what you are asking for.
Simon
Its actually easier than it looks.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
-
Which capable to retrieve and store data as CLR objects. :)