|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 27
Messages: 27
Messages: 27
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ask TheServerSide.NET: Is DLINQ just another ORM?
The announcement of the Language Integrated Query (LINQ) features of C# 3.0 has caused both excitement and apprehension. While most think that query integration in the language is a good thing, the DLINQ extension appears in many ways to be just another object relational mapper. Is Microsoft changing the way data applications are developed or just reinventing the wheel?
While the technology is in its infancy, quite a bit of new information has been released subsequent to PDC. By creating objects with table relational attributes, are we able to bridge the impedence mismatch that Anders has discussed previously or is this just an attribute based form of table/column mapping?
What do you think? Will this be useful in your applications in the future? What will this mean to commercial and open source ORM tools in the .NET market?
|
|
|
Message #186317
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
attribute driven mapping
Having seen cases where a developer decided to use attribute based mapping to tables, it is very limited. Almost immediately out of the gate, the approach broke a ton of code in the other projects, which resulted in reworking the framework. Attribute based approach works well if you only have 1 database model to integrate with and don't have to support multiple models as the product/project evolves.
If an application has to integrate with multiple data models and provide an elegant way to evolve, I would say it's better to separate the mapping from the objects. Although, I suppose one could write custom attributes to allow for many-to-many mapping, it feels rather heavy. In a production environment, I'd rather not recompile my code to account for the fact that I've made a materialized view to improve a multi-table join.
Some other approaches to this kind of problem are solved by having a mapping language like http://jibx.sourceforge.net/. Although JIBX is written in java, it's open source and anyone can easily port it to C# and .NET.
I know of a few projects that have exactly this type of problem because the data access layer was mapped to 1 data model and didn't use mapping techniques. This approach can lead to writing multiple data access layers for each data model. By the time I got to the project, they had a half dozen data access layers for each product to account for changes in various data models. A generic object query mechanism is good for adhoc queries of loaded data, but it really shouldn't be used as data mapping. As murphy would say, "what can go wrong, will go wrong."
peter
|
|
|
Message #186340
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reinventing the wheel?
Firstly, DLINQ needs to be seen in the context of the rest of LINQ: the absence of query facilities over collections of objects has been a gaping hole, and it would be silly to address that without adding a database dimension.
Other than that, I think the only people likely to regard this as reinventing the wheel are people who sell wheels...
|
|
|
Message #186344
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Language addons are always welcome
I think language addons are always welcome when they come from the need of programmers to write code easyer. There is however a limit from where the language becomes too complex to understand by "human beings" (PERL is pretty cool, but how many of us are using it). Personnaly, mixing SQL sintax to OOP is somehow scary, because I just imagine how the code will look for someone who hasn't a very clear image about what is going on, mixing code.
Huge performance drawbacks can be generated by wrong application design - and this can be easily achieved by using these out-of-the-box functionalities which seem to solve all your problems.
For now I'm more interested in the workflow engine that will be introduced in the next version. This will be a huge change in the way we write code. The language will become more and more useless, the same for it's addons.
|
|
|
Message #186424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Enhancing the language
I think there are benefits for ORM based development that can only be achieved by enhancing the programming language: It certainly is a huge benefit that your query language is checked during compile time and not during runtime (using DLINQ). The earlier an error is detected the higher the quality. The other mismatch between programming languages and DB's I always hated is that we didn't have nullable primitive types (in most programming languages). This enhancement of the newer .NET Framework is the other big advantage that MS introduces for developers that deal with DB's.
|
|
|
Message #186427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ask TheServerSide.NET: Is DLINQ just another ORM?
I wrote about what I think its wrong with the DLinq implementation here
To answer the questions :
"Is Microsoft changing the way data applications are developed or just reinventing the wheel."
It's just reinventing the wheel. There is nothing groundbreaking about Dlinq. After watching the LINQ preview on Channel9 i was actually a bit sad to see the C# father acting like a PR man and hyping DLinq like it's some sort of a groundbreaking technology. The first O/RM was build in Smalltalk before I was even born (some 30 years ago). LINQ is pretty good though.
"By creating objects with table relational attributes, are we able to bridge the impedence mismatch that Anders has discussed previously or is this just an attribute based form of table/column mapping".
Actually a O/RM bridges the impedence mismatch. The attribute part is just a implementation detail. See the link above if you are interested on why i think attribute based mapping is a wrong choice.
"Will this be useful in your applications in the future?"
Absolutely. A O/RM is of a tremendous step forward from a ADO.NET perspective.
"What will this mean to commercial and open source ORM tools in the .NET market? "
My take as a O/RM vendor is that there isn/t much to be worried (now). Dlinq is NOT a top notch O/RM and it doesn't seem to be database independent. Another problem with Dlinq is that is 1-2 years away from release. Why wait for so long ? <shameless plug> If you're interested in a .NET 2.0 O/RM give DataBlock a try.
</shameless plug>
|
|
|
Message #186481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the Future will Support LINQ
I had the privilege of attending the PDC this year and hearing these questions answered for myself by Mr. Hejlsberg, Mr. Box, Mr. Lucas, and others. It is clear from the talks at the PDC, that the first versions of DLINQ will be really simple by design. There is no way that is meant to, or will replace existing ORM systems (initially at least). The integrated language extensions are an awesome enhancement to the .NET languages and everyone will use them.
An ORM in the future will support LINQ extensions in an intelligent way. For example, more sophisticated handling of recursive queries, inheritenance, composition, mapping files, database independence, etc... Out of the box from MS, you'll get very basic ORM-ish like behavior from DLINQ. The enterprising open source or commercial ORM will see this as a real blessing because the ORM concepts are being mainstreamed into the commercial .NET languages!
|
|
|
Message #186705
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
attribute driven mapping
If an application has to integrate with multiple data models and provide an elegant way to evolve, I would say it's better to separate the mapping from the objects.
How often does that really occur?
Other than a couple utilities I wrote to move data between incompatable databases, I cannot think of a single program I've written that didn't have hard-coded database information.
In a production environment, I'd rather not recompile my code to account for the fact that I've made a materialized view to improve a multi-table join.
If it is a production environment, the couple of minutes it takes to recompile is nothing to the couple of hours even a trival regression test takes. Unless, of course, you don't belive in testing database changes. An unfortunate, though all to popular, view in our industry.
Jonathan
P.S. Murphy's law is, "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." What you quoted is not only inaccurate, but untrue. Things that can go wrong don't always go wrong.
|
|
|
Message #186707
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ask TheServerSide.NET: Is DLINQ just another ORM?
I like the video with Anders' presentation (as I always like his clear and crisp talks BTW). I don't know if DLINQ can completely replace existing OR-Mapping-Tools as I didn't see how they will integrate the modification scenarios.
What I really like is how LINQ will generally change the way how we collect and filter data. As Anders describes we usually have to write quite a lof of code to filter some data we have at hand (for-loops, checks, string-conversions etc.) The descriptive way of writing the filter makes the intention of the code immediately accessible to the reader of the code and the code shorter in the whole. Besides having the syntactic sugar (from,where,select etc) it also seems to be cleanly integrated in the language, it isn't just an add-on.
Plus, the language features like the Extensions strongly remind me of the useful Mixin classes of Ruby. C# now seems to speed up in development compared to the slow progress of the Java language.
|
|
|
Message #186720
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the Future will Support LINQ
I find it funny that many people think as DLinq as a O/RM product. It's like saying that ADO.NET is an O/RM product.
DLinq is intended to be much less than that - it is an interface between LINQ-based C# queries and SQL Server databases. It is the equivalent of the ADO.NET provider in the LINQ world. In fact the term ORM is never mentioned in the DLINQ overview document...
So DLINQ is, if you want, more like a low-level building block than a full-fledged ORM product.
Now, about "reinventing the wheel" thing. Technically, this whole alphabet soup coming from Microsoft guys (DAO, Jet, ODBC, OLE DB, ADO, ADO.NET and now DLINQ) are succesive reinvetions of the same wheel - how to query data in a simple manner. The advances here from one step to another are incremental, and more in the sense of "easy of use" at the API level. We can see that, starting with the OLE DB to ADO and then ADO.NET, the language itself plays a increasingly important role - the end goal here is eliminating the boilerplate code that "links" C++/C# in-memory structures with SQL query concepts.
Second thing - DLINQ does not mandate attribute-based mappings. You can use the following code to issue a query:
Northwind db = new Northwind("c:\\northwind\\northwnd.mdf");
var q =
from c in db.Customers
where c.City == "London"
select c;
foreach (var cust in q)
Console.WriteLine("id = {0}, City = {1}",cust.CustomerID, cust.City);
Here, you didn't had to define any prior structures of the Customers table - the mapping is decided without explicit programmer support.
I personally think that DLINQ is just the beginning, and the real power is in the extensible LINQ infrastructure. I wouldn't be surprised to see an OLINQ (for querying Oracle databases) or a DBLINQ (for issuing generic queryies on a certain OLE DB provider which is chosen at runtime).
|
|
|
Message #186742
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
DLinq is intended to be much less than that - it is an interface between LINQ-based C# queries and SQL Server databases
No...it's not. DLinq IS a O/RM. Your statement about "interface between LINQ based C# queries and Sql Server" would be true if Dlinq would be used ONLY for querying. BUT IT'S NOT !!!! With SubmitChanges , Update/Create/Delete queries are generated by DLinq and sended to the database. So Dlinq is not used only for querying. Let's see...with DLinq we have a (bad) way to
map database tables to objects, possibility to query data and send changes back to the database. And surprise surprise...this is what a ORM does (between other things). So after all Dlinq is a ORM. I mean....why do MS people insist in NOT calling DLinq a ORM ?!! I mean....if it looks like a bear...it walks like a bear.....you get the point.
So DLINQ is, if you want, more like a low-level building block than a full-fledged ORM product.
How come ? Let's say i want to use Dlinq with a Firebird database. Would i be able to do that with Dlinq out of the box ?
Of course not. So let's talk about this "building block" :
- Dlinq saves Sql Server specific information in the mapping attributes . How the heck is this useful to me when i work with Firebird. Also how do i make it use datatypes which don't exists in Sql Server ?
- based on the Dlinq query a expression tree is generated. How do i access this expression tree so i can generate the query for Firebird ?
The design decisions for DLinq show pretty clear that this is a SqlServer based product.
Now, about "reinventing the wheel" thing. Technically, this whole alphabet soup coming from Microsoft guys (DAO, Jet, ODBC, OLE DB, ADO, ADO.NET and now DLINQ) are succesive reinvetions of the same wheel - how to query data in a simple manner
It was NEVER EVER EVER EVER about how to query data !!! It's about WORKING with data. There is a huge difference between those 2 concepts. Think about this....you query the database, you manipulate the data and you update the database. The easier is to do this 3 operations...the better. Let's make a short comparation between ADO.NET and DLinq on how you achieve these things :
- you query the database using text queries or stored procs. With DLinq you query the database with a TYPED query. That is a big bonus in functionality because the query is typed. The downside is the DLinq approach is slower because of the "conversion" between the expression tree to SQL. But the typed thingie is sure worth it.
- you get back the data (doesn't matter if we're talking about projection or data from a single table). In the ADO.NET case
(DataTable) the problem is that the data is untyped ( please don't bring up the typed datasets). You can work with data using the very limited DataTable.Select() method ( which for crap sake doesn't even supports joins between 2 data tables and also it uses a "like SQL" but not really SQL). It supporta only a primitive way of working with data. So you end up writing TONS of code (loops and stuff) trying to emulate event simple SQL like query results. To summarize....ADO.NET pretty much blows chuncks when working with data. And this is where Linq comes in with his typed queries and SQL like functionality for "in memory" data structures. For the next version of <href
DataBlock i wrote a implementation of a object query language (nicknamed Karmencita) which pretty much works like Linq (minus the typed thingie).
ObjectQuery<Customer> oq = new ObjectQuerty<Customer>();
decimal x = oq.Sum(c.GetField("Salary"), "Age > 34 and Name LIKE C%");
To summarize : big win for DLinq over ADO.NET here.
- send changes back to the database.
With DLinq(and any other O/RM) you do that with a single line of code xxx.SubmitChanges(). There is no equivalent to this is ADO.NET. You must manually write the queries for UPDATE, DELETE and Create which is pretty painful and time consuming. This is the area where DLinq (and any other O/RM) blows ADO.NET out of the water and skyrockets the programmer's productivity.
Second thing - DLINQ does not mandate attribute-based mappings. You can use the following code to issue a query:
This is simply not true. The typed DataContext (Northwind) contains lists with the mapped objects. The mapping information is used even for things like Intellisense (not to mention that LINQ's SQL like query was changed JUST so we can have Intelisense when writing the queries). Without the mapping information you can't have typed queries.
Also another reason your point is wrong is simply because nobody is using DLinq JUST for querying data( See the above comparation between ADO.NET and Dlinq) and the CREATE/DELETE/UPDATE queries REQUIRE the mapping informations.
I personally think that DLINQ is just the beginning, and the real power is in the extensible LINQ infrastructure. I wouldn't be surprised to see an OLINQ (for querying Oracle databases) or a DBLINQ (for issuing generic queryies on a certain OLE DB provider which is chosen at runtime).
This comment show pretty well that you Microsoft guys just DON'T GET IT.
|
|
|
Message #186754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
that's your experience, but not mine
If an application has to integrate with multiple data models and provide an elegant way to evolve, I would say it's better to separate the mapping from the objects.
How often does that really occur? Other than a couple utilities I wrote to move data between incompatable databases, I cannot think of a single program I've written that didn't have hard-coded database information.
In a production environment, I'd rather not recompile my code to account for the fact that I've made a materialized view to improve a multi-table join.
If it is a production environment, the couple of minutes it takes to recompile is nothing to the couple of hours even a trival regression test takes. Unless, of course, you don't belive in testing database changes. An unfortunate, though all to popular, view in our industry.
Jonathan P.S. Murphy's law is, "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." What you quoted is not only inaccurate, but untrue. Things that can go wrong don't always go wrong.
As I said, if a given project doesn't need flexibility and doesn't have to integrate other systems, then hardcoding is fine. I've mainly worked on services and integration environments. In these kinds of environments, mapping is preferable.
My point about not having to recompile is because in service environments, the cost of recompiling may require a formal regression test that takes 3 weeks. I don't know what others do, but the cases I've seen, changing a simple mapping goes through one set of regression tests. Recompiling requires a much wider set of regression tests. Go ask MSN how they deal with difficult integrations with all their partners. Rolling out code changes in large scale sites often have formal processes, which means regression testing isn't just running a dozen tests. The tests may be over a thousand.
If a project is reasonably assured the data model won't change more than once a year and the release cycle is well established with formal regression testing, then hardcoding is probably going to be eaiser. If not, it's totally inappropriate.
peter
|
|
|
Message #186758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
DLinq is intended to be much less than that - it is an interface between LINQ-based C# queries and SQL Server databasesNo...it's not. DLinq IS a O/RM. Your statement about "interface between LINQ based C# queries and Sql Server" would be true if Dlinq would be used ONLY for querying. BUT IT'S NOT !!!! With SubmitChanges , Update/Create/Delete queries are generated by DLinq and sended to the database. So Dlinq is not used only for querying. Let's see...with DLinq we have a (bad) way tomap database tables to objects, possibility to query data and send changes back to the database. And surprise surprise...this is what a ORM does (between other things). So after all Dlinq is a ORM. I mean....why do MS people insist in NOT calling DLinq a ORM ?!! I mean....if it looks like a bear...it walks like a bear.....you get the point.
So, let's see - we have the DataTable construct in ADO.NET which allows a table-to-object mapping (including queries, updates, deletes). By your definition, this automatically makes ADO.NET a ORM product, correct? Wrong.
DLINQ might "look" like an ORM product but this doesn't mean that it was designed to be a ORM product. Not. It was designed to address specific engineering challenges, primarily around integrating SQL-style queries in your app.
And judging DLINQ from the ORM point of view is probably not a very useful thing to do. It sounds more like an academical appraoch: it's like judging C++ from the OOP opint of view. From the pov of an OOP purist, C++ might be a "bad" example of an OOP programming language. Maybe. But who cares? Just look where C++ is now, and compare its success with the success of Smalltalk, for example.
I guess that Microsoft adopted here an evolutionary approach - by coming up over time with better and better abstractions on the same old problems. But more importantly, by not attempting to do something that they don't have 100% guarantee that is the right thing to do.
This prudent, bottom-up approach contrasts sharply with coming up with a top-down approach where one attempts to design a universal framework that pretend to do everything :
1) Abstact any operations on every database in the world
2) Deal intelligently with data caching
3) Perform real-time optimizations on database access
4) integrates nicely with existing data stores
5) implements anti-gravitation
6) brings peace on earth
7) solves the global warming problem, etc.
It is very hard, maybe impossible to come up with an universal framework that attempts to solve every DB problem on earth. Proof is that, in the past, whenever someone attempted to come up with such universal frameworks, either they either got burned badly, or the resulting framework was too slow compared with native database access, or they had to focus only specific products. The trouble usually starts when you want to implement efficient DB applications.
I believe in an evolutionary approach on all these concepts. LINQ offers a nice framework for queries (you can add updates too on top of that - but my personal take is that's not the innovative part).
Thanks, Adi
P.s. BTW - these are just my personal opinions - I am not 100% sure if the LINQ team would agree with whatever I said. I would be curious what is their opinion on all this.
|
|
|
Message #186790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
So, let's see - we have the DataTable construct in ADO.NET which allows a table-to-object mapping
(including queries, updates, deletes). By your definition, this automatically makes ADO.NET a ORM product, correct? Wrong.
No ...we don't. The DataTable is JUST a "generic" data structure who's schema is build at runtime from the query resultset. There is no table-to-object mapping ! You send a plain text SELECT query (which can't be verified for validity at compile time) and you get a DataTable
which is created as i described above. There is no mapping here. On the other hand with a ORM you get a instance of the mapping object.
It's simply apples and oranges. Also....DataTables don't "map" (or create automatically) create /delete/ update queries but an ORM does. That's why i've said that the programmer's productivity skyrockets when it's using a ORM. Also not to mention "business objects" (which unfortunetly are missing from DLinq).
DLINQ might "look" like an ORM product but this doesn't mean that it was designed to be a ORM product
Let's not play with words here. It really doesn't matter how it was designed AS LONG as it "acts/looks" like an ORM.
Also....pure unbiased third party opinion here...but i think the ObjectSpaces arhitecture was better than DLinqu's.
And judging DLINQ from the ORM point of view is probably not a very useful thing to do.
Personally i'm not judging DLinq from a ORM perspective. I'm judging it as a tool which will allow me to do my job. And, with its current implementation DLinq just doesn't cut it.
This prudent, bottom-up approach contrasts sharply with coming up with a top-down approach where one attempts to design a universal framework that pretend to do everything :
We agree here. In the world of "data access" i also think there isn't a single "best way" to write data access code. But experience taught me that the ORM's dynamic generated sql works in 90% of the cases. There ARE ORMs there (heck i write one) which can abstract RDBMS operations (it's funny that most people don't realise that the difference between RDBMS is simply their "dialect" of SQL) and pretty much allow you to run a unmodified application on multiple RDBMS. So this can be done. Microsoft will NOT do that because.....well...we both know why.
Related to caching.....this is a very interested topic. Why doesn't Microsoft attempts to satisfy the request of their clients and offer us distributable transactionable caching ?!! This is very very useful in high performance scenarios because it pretty much allows us to "treat" the database as a in memory data structure. Combined with Linqu's ability to query the data this would be a very compelling scenario. Does MS has any plans to offer us this ? No ?! I thought so....
Don't know about world peach and global warming though :)))
"or the resulting framework was too slow compared with native database access, or they had to focus only specific products. The trouble usually starts when you want to implement efficient DB applications.
You're wrong. Have a look in the Java world and see real life applications implemented using JDO/Hibernate/Cayenne. Speed is NOT the issue here. If we were interested PURELY in speed we would still banging C code and connected to SQLServer using TDS. But we evolved.....
Thanks,
Marius
|
|
|
Message #186799
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM and Distributed Object Caching
Distributed/Clustered caching hasn't really been addressed in .NET by Microsoft. But, my company (Alachisoft) has developed a distributed/clustered object cache for .NET that is very powerful and fills this gap very effectively.
Check it out at http://www.alachisoft.com and email me your thoughts.
Iqbal M. Khan
iqbal@alachisoft.com
|
|
|
Message #186853
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
So, let's see - we have the DataTable construct in ADO.NET which allows a table-to-object mapping (including queries, updates, deletes). By your definition, this automatically makes ADO.NET a ORM product, correct? Wrong. No ...we don't. The DataTable is JUST a "generic" data structure who's schema is build at runtime from the query resultset. There is no table-to-object mapping ! You send a plain text SELECT query (which can't be verified for validity at compile time) and you get a DataTablewhich is created as i described above. There is no mapping here. On the other hand with a ORM you get a instance of the mapping object.It's simply apples and oranges. Also....DataTables don't "map" (or create automatically) create /delete/ update queries but an ORM does. That's why i've said that the programmer's productivity skyrockets when it's using a ORM. Also not to mention "business objects" (which unfortunetly are missing from DLinq).
>>> There is no table-to-object mapping!
Huh? So - let's pick up the following DLINQ query:
var ids = (
from c in db.Customers, e in db.Employees
where c.City == e.City
select e.EmployeeID );
foreach( var id in ids)
Console.WriteLine(id);
Can you please explain to me where do you see the "table-to-object" mapping here? What would every instance "id" above mean in the context of your "object-to-table" mapping?
DLINQ might "look" like an ORM product but this doesn't mean that it was designed to be a ORM productLet's not play with words here. It really doesn't matter how it was designed AS LONG as it "acts/looks" like an ORM.
I deeply disagree with you - the design of any product matters more than whoever it might "look" like.
"or the resulting framework was too slow compared with native database access, or they had to focus only specific products. The trouble usually starts when you want to implement efficient DB applications. You're wrong. Have a look in the Java world and see real life applications implemented using JDO/Hibernate/Cayenne. Speed is NOT the issue here. If we were interested PURELY in speed we would still banging C code and connected to SQLServer using TDS. But we evolved.....Thanks,Marius
You might live in a world where speed does not matter, but that's not the case with many customers. For one thing, do you know why database indexes were created? To ensure fast response times in things like queries (for example 200 ms as opposed to 10 minutes). So, yes, performance matters, I guess. If your customer do not care about speed, fine :-). But you shouldn't generalize this to a all-encompassing blank statement like "speed is not the issue".
Thanks, Adi
|
|
|
Message #186854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
And, one more query for you, Marius :-)
var ids = (
from c in db.Customers, e in db.Employees
where c.City == e.City
select new {e.EmployeeID, c.ContactName} );
foreach(var id in ids)
Console.WriteLine(id);
Same question - what would the "ids" collection represent in terms of your "table-to-object" mapping?
Thanks, Adi
|
|
|
Message #187163
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Linq seems to the newbie like a new OQL
Hi,
from the syntax I see the queries are very much like Object Query Language and it's descendents like HQL that comes with hibernate/nhibernate on .net. Just as an example:
HQL:
select mate
from eg.Cat as cat
inner join cat.mate as mate
or
from eg.Cat as cat
inner join cat.mate as mate
left outer join cat.kittens as kitten
or
select cat, count( elements(cat.kittens) )
from eg.Cat cat group by cat
so to me which I use this every day, I don't see anything groundbreaking in LINQ. Or maybe I haven't read enough about it.
Dan Bunea
http://danbunea.blogspot.com
|
|
|
Message #187164
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ask TheServerSide.NET: Is DLINQ just another ORM?
Is Microsoft changing the way data applications are developed or just reinventing the wheel?
Well...hate to say this but they are (as ussual) re-inventing the wheel and in the worst style. Looks like they have not assimilated yet (properly) the experiences of 30+ years of OO technology.
I think ObjectSpaces was a much more mature idea...
|
|
|
Message #187169
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
Hi Adi,
Before answering the question i just want to say <rant> that type inference makes the code almost unreadable (especially since ALL the Linq/Dlinq samples i've seen use it).
In C# 1.0 by looking at one line of code you could tell what it does. This "ability" is lost now. Every time you'll see var (also ...why var ? C# it's not Pascal)
you'll ALWAYS ask yourself....."what the heck is the type of that variable ?". </rant>
Ok...so related to the question. First of all we should not mix in the discution database operations (like the aforementioned query) and the underlying "technology"
used to execute the query. That query is BUILD using the mapping information supplied by DLinq. That query is typed because of the DLinq mapping. So the "magic"
that makes it possible to run the query is....mapping. Now related to the database operations (eg...the ids in your sample) and what it means in the context of "object-to-table" mapping....
The ids could be
- a List<int>
- a List<Customer> and each member of the List<Customer> has a valid Id and the rest of its members are null.
The second case is pretty clear. You return the result as list of instances of mapped objects. In the first case (List<int>) the "instance id" don't mean anything in the context of
"object-to-table" mapping. WHY do you expect to "mean" anything in this context ? It's just the result of a database query. The result can be a single value (ExecuteScalar),
a list of values from a single "column" (like the list of ids), a result of a projection query etc. Also...a very important note here....since in that video
mr Hejslberg mentioned that DLinq will be part of the next ADO.NET version....i think it is VERY important that Dlinq should "play nice" with DataSets/DataTables and the results
of those DLinq queries can be returned as DataTables. In this way the code can slowly migrate from "in line sql/stored procs" to Dlinq queries BUT the code that processes
those results remain the same.
"I deeply disagree with you - the design of any product matters more than whoever it might "look" like."
I think it pretty much pointless to further argue about this. To me personally Dlinq looks/works like your regular ORM.
"You might live in a world where speed does not matter, but that's not the case with many customers. For one thing,
do you know why database indexes were created? To ensure fast response times in things like queries (for example
200 ms as opposed to 10 minutes). So, yes, performance matters, I guess. If your customer do not care about speed,
fine :-). But you shouldn't generalize this to a all-encompassing blank statement like "speed is not the issue"."
You misinterpreted my words. I said that speed is not the main issues. In "my world" (the world of a guy which writes busieness applications
for a living), the cost and time to market are more important than speed. I'm going to say it again....if SPEED WAS THE MOST IMPORTANT FACTOR in
a business application WE WOULD still be coding in C. But we dont'...GC, scripting languages, no pointers :), virtual machines etc.
All these throw away the issue of "raw speed" and favour "productivity". Also "raw speed" it not really important in a business app. Things like inteligent
caching are much more important for the overall "speed" of the application. Also it's pretty funny to argue about speed in a context of a discution about Dlinq.
It's FASTER to call a stored procedure than to generate + execute a dymanic SQL based on mapping information "grouped" in a expression tree. But the
DLinq is way better than stored procs in so many ways. So, you see, speed is not the main issue here.
What about the MS guys who work on Navision.....do they code in asm ? :))
PS :Dan HQL is not typed. LINQ is.
Thanks,
Marius
|
|
|
Message #187216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
Ok...so related to the question. First of all we should not mix in the discution database operations (like the aforementioned query) and the underlying "technology"used to execute the query. That query is BUILD using the mapping information supplied by DLinq. That query is typed because of the DLinq mapping. So the "magic"that makes it possible to run the query is....mapping. Now related to the database operations (eg...the ids in your sample) and what it means in the context of "object-to-table" mapping....The ids could be - a List<int> - a List<Customer> and each member of the List<Customer> has a valid Id and the rest of its members are null.The second case is pretty clear. You return the result as list of instances of mapped objects. In the first case (List<int>) the "instance id" don't mean anything in the context of "object-to-table" mapping. WHY do you expect to "mean" anything in this context ? It's just the result of a database query. The result can be a single value (ExecuteScalar),a list of values from a single "column" (like the list of ids), a result of a projection query etc.
>>> WHY do you expect to "mean" anything in this context ?
I guess I don't see what you meant by "table-to-object mapping". You presented this "table-to-object" mapping as a crucial differentiator between ADO.NET on one side, and DLINQ/ORM on the other side, so this is why I wanted to understand what do you mean by this. I guess that by "table" you meant a database table, but which "object" are you reffering to in the context of the query above? I don't see what this "object" would mean from DLINQ point of view, especially given that LINQ queries can also return projections, as the one as I presented above (combining the results from two tables with a SQL join). So, DLINQ is different than ORM, after all :-). There is no “table-to-object” mapping there either :-)
If all you wanted to say is that DLINQ infers the database schema using some implementation technique (generating a predefined structure of C# classes), that's a different story. With the current (early) version of DLINQ you can infer this database schema using SqlMetal.exe, which generates from the schema a set of (roughly equivalent) set of C# classes (many-to-many associations don’t work however). SqlMetal extracts from the SQL Server database schema information like what are the primary keys, foreign keys, field types, for each table etc. and can infer things, for example what fields (or combination of fields - not sure if this is supported yet) can be used as an "identity" in a certain DLINQ query result set.
In fact, I believe that the set of classes are there just to: (1) ensure strong-typing, through the C# feature set, and (2) offer a runtime representation of the database schema (which probably gets optimized at the first run in an in-memory format). This in-memory representation of the database schema is very useful because you can then easily figure out the exact SQL commands at runtime. For example, in my last query, DLINQ would know how to generate a SQL join, and will expect typed parameters from that query.
A similar (but much more primitive) approach is possible with ADO.NET too - you can generate a strongly-typed ADO.NET recordset through a VS.NET wizard. (and BTW, ADO.NET also supports a primitive form of CRUD support in the DataAdapter class). But you don't have there the ability to generate the optimal SQL queries, or the ability to infer the identity of the returned "rows" so you can keep track of the changes over time, etc.
So I think that DLINQ is a big improvement over ADO.NET here.
I also believe that DLINQ is below at the level of a full-fledged ORM product (and we seem to be agree with this, don't we?). But that was never the intention, so positioning DLINQ as an ORM product would be unfair and misleading, don't you think?
And, yes, I trust Anders - I presume that you should be able to naturally convert a LINQ result set in a DataSet.
Thanks, Adi
http://blogs.msdn.com/adioltean
|
|
|
Message #187218
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
O/RM of the future will support LINQ
>>> I also believe that DLINQ is below at the level of a full-fledged ORM product (and we seem to be agree with this, don't we?). But that was never the intention, so positioning DLINQ as an ORM product would be unfair and misleading, don't you think?
Disclaimer: By the way - all this stuff I posted here is just my personal opinion, and don't take it as the Microsoft opinion. The LINQ team might or might not agree with whatever I rambled on this thread :-)
|
|
|
Message #187234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ORM over Function
Is DLINQ an ORM? The definitive answer: sort-of. It's not meant to be the end-all uber mapping system. In fact, in its current state it doesn't do much of any mapping at all. DLINQ is primarily using CLR metadata to encode database schema. Will it do more mapping in the future? Yes. How much more? It depends on feedback and where we estimate the sweet spot to be. It is doubtful it will ever become as mapping rich as products such as Hibernate. That's not our target with DLINQ. There will continue to be a healthy ecosystem of ORM products in the .Net space. Hopefully, most of serious ones will look to language integrated query as an opportunity.
Our strategy with DLINQ is to start with the easy to understand concepts and get those right, building up conservatively. At its base, we hope DLINQ will be able to reach a wide audience of developers, many of which have never considered ORM as a development solution. For these developers, we want the 'out-of-the-box' experience to be incredibly simple: point at the database, press a button and start writing queries. From there we want DLINQ to scale up to more regimented practices, where object models are designed and databases are managed. We are not there yet.
As for DLINQ not being described as an ORM, I have to admit I peronally went throught the overview document and removed most references to the word 'mapping.' Those familar with ORM recognize it when they see it. To everyone else its confusing jargon. I have to tell you, however, that at the PDC recently, a few ORM vendors came to me and thanked us for presenting DLINQ. They we amazed how potential customers where now approaching them already understanding what their products were meant to do. They were used to getting a lot of vacant stares.
|
|
|
Message #187379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ask TheServerSide.NET: Is DLINQ just another ORM?
What I expect from LINQ & DINQ.
What is LINQ & DINQ? It seems to be an integrated typed queries engine. Is it one? If yes – why not to support it in various existing persistent layers? The only question is – Is it possible to use and extend it in other way than it offers?
Everything I saw seems to be a hard coded extension of C# language and it’s in my opinion makes it not so flexible. I think that the next language generation should give an advantage for third-party developers to extend programming language with additional operators and syntax constructions that will be checked at compiler time. Something like - compiler extensions. That could be a real next-generation feature. For example One writes OR mapper and includes as extension SQL-LIKE commands in his library. Another One writes MATH library and includes some extra MATH operators. In other words – extensions of the basic-language (C#1,2,3) as code-library with full control other extended syntax at runtime.
Of course such a syntax-extensions could bring a lot of chaos. But operators overloading and generics also make code less understandable but from the other hand they give lots of advantages.
Is LINQ ORM ? – No. Is it a Query engine? –Yes, if I would be able to support and use it in the library of mine for querying my datasource and I would be able to generate a code like I want.
Thanks,
Andrey
Chef Developer
www.lastcomponent.com
|
|
|
Message #188545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Advanced Query Languages
DLiNQ is supposed to be an object-oriented query language, but IMHO an ugly one. I think that Native Queries (http://www.db4o.com/about/productinformation/whitepapers/) are much more elegant. As for being an O/R mapper, there's bound to be one coming soon, and there is room for it in the DLINQ design. In fact, it sort of implies that there is an ORM functioning at the root of DLINQ expressions. But ORMs can't hold a candle to newer ODBMS systems: www.odbms.org
|
|
|
Message #190969
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Linq will be supported, DLinq is just a study
As developer of an O/R mapping solution (see www.netdataobjects.com) I can say, that DLinq is just a study and doesn't provide much value for real world development.
What really matters is the standard query language for all kind of search stuff. So, NDO, my product will make use of the QueryExpressions pattern to allow Querys like
from c in pm.Customers where c.City == "London" select c;
The Xml mapping file will determine, what "Customers" "City" etc. means. This Query Expressions pattern together with the new C# Keywords is kind of a standardisation of query languages in .NET and looks very much better than the standardisation efforts in the java world (JDO, ODMG).
If you need more info about that stuff, read:
http://download.microsoft.com/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.doc
|
|
|
Message #209800
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Something old that microsoft tries to make look new
What's amazing is that languages like Powerbuilder's PowerScript has been doing this since the 90's. Granted, it was specifically tuned for sql, but it's been there since then and is still there.
This is there old "embrace and extend" mantra. I look forward to it in some ways, however.
PB example:
string username
long uid, level
uid = 10
select username, accesslevel into :username, :level
from usertable where userid = :uid using SQLCA;
messagebox('user name', username)
========================
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
