I wrote a comment to the DLinq PM blog (http://blogs.msdn.com/dinesh.kulkarni) couple of days ago with some critics to Dlinq mapping. It seems to me that Microsoft employees don't take critics too well because my comment got deleted. So i have decided to write them here. So here they are :
Attribute based mapping. Atrribute based mapping has a few disadvantages :
- it's slow. Due to heavy usage of the Reflection API it's slower than Xml based mapping
and , of course, a heck of a lot slower then direct mapping calls.
- it needs a separate API that you need to learn to extend DLinq.
- the mapping atrributes need to be cached for further reuse. Now imagine
what happens when mapping attributes of 100 database tables are cached....the working set goes to the roof.
There are basically 3 ways to map database schema info : attribute mapaping, xml mapping and direct mapping (which
we used in DataBlock). With attribute based mapping MS made the worst choice between those 3.
Database specific attributes mapping :
This pretty much by itself should give us a clue that MS doesn't want DLinq to play nice with other RDBMS vendors.
It saves Sql Server specific types in the attributes mapping. If you want to create a RDBMS independent O/RM that's
definitely a no no. Another problem with their mapping is that it doesn't support type which are not supported by Sql Server.
How would i map a PostgreSql Point type with Dlinq ?
DataContext
So the DataContext itself it pretty much a database connection. In a database independent O/RM a database connection
is pretty much described by 3 attributes :
- connection string
- database server type (Sql Server or PostgreSql for instance).
- provider used to connect to the database. This may not be useful if you're working with SqlServer only but
it's very useful when working with 3rd party RDBMS.
DataContext uses only a connection string. So it seems that there is no way for Dlinq that allows you to use a different
database server then Sql Server. In the documentation it's mentioned a "strong typed connection" using a class which
derives form DataContext. The downside of this approach is that you HAVE TO ADD THE mapped objects to the DataContext !!!!
Why ?! Why ? A mapped object...it's just that....a object. A POCO (Plain Old CLR Object). Why do you constrain me to
associate it with a typed DataContext ?
Another problem with their DataContext approach is that is too low level. In a business application you usually have business
objects to whom you pass these mapped objects and , from there, they go to the database. With a DataContext i'm sure there
will be plenty of people who will update the database from the event handler in the GUI. That's bad...
So there you go....this is what i think it's wrong with the current architecture of DLinq so far.
Subscribe