I guess I am in a fiesty mood this Friday, because I am “taking on” those .NET Developers who continue to belittle DLinq, a .NET O/R Mapper from Microsoft that is attribute-based and apparently targeted for SQL Server.
The opposition seems to be from current O/R Mapper vendors and apparent enterprise developers who feel a dis-service that Microsoft hasn't provided a .NET O/R Mapping solution that is more universal with regards to other databases and more focused on enterprise developers.
First, other O/R Mapper vendors have a vested interest to bash DLinq for financial reasons. This isn't to say that their technical reasons don't have merit. It is just to say that their opinions are biased as this is how they make a living, making O/R Mappers. Microsoft's DLinq will likely take a chunk of their potential customer base. Beware of their opinions.
Second, what is all this talk from enterprise developers about wanting support for other databases beside SQL Server. I don't want a solution that includes everything and the kitchen sink. It would probably be insanely slow and difficult to maintain, which would give developers another reason to complain. I applaud Microsoft with a SQL Server-only solution as most Microsoft-related developers who would use DLinq in the first place would probably only be developing for SQL Server anyway.
Let me say that I am not a fan of attribute-based O/R Mappers from an enterprise development perspective. I don't like the idea of adding persistent meta-data on my persistent-ignorant business classes. Domain objects are focused on the problem domain and should focus only on the data they encapsulate and the responsibilities that act upon that data. Persistence information is best located in a separate cohesive layer that focuses on persistence and plugs into the application framework.
However, let's be serious. How many corporate contracts or companies have you worked that would touch an O/R mapper with a 10-foot pole? Probably none of them. And, no, it is not because O/R Mappers are not mature. It is because some have the dreaded Not-Invented-Here Syndrome and some are a bit controlling and want Pure-ADO.NET that they can tweak to the cows come home. I am not saying this is wrong. In fact, it is probably very smart as I tend to go the route of hand-coded ADO.NET for more sophisticated applications myself.
From a small business and rapid application development perspective, I have to say that the same rules don't apply. Let me have a solution, such as DLinq, that is SQL Server focused and for which Microsoft-related developers can easily understand and maintain. Additional objects and extensible frameworks that try to loosely couple layers for absolutely no good business reason only force an increase in skill-level and maintenance costs. DLinq is perfect for those developers who focus on small applications and Microsoft-related technologies.
You say you want a solution that targets not only SQL Server but other persistent solutions? You say you want a solution that is not attribute-based because you think it won't scale well or muddies-up your domain layer? I say you have a whole bunch of solutions on the market now and don't need to rely on Microsoft for such a solution.
I respect and certainly support the developers who are voicing their opinion about DLinq, because it helps me understand the possible risks with such a solution. However, I think those developers need to come clean and explain their biases and the context in which they convey their opinion. I envision a whole population of developers, including myself, that can't wait to develop with DLinq. Just because it only serves a particular segment (or role) of developers and cuts into the revenues of current 3rd party O/R Mapper vendors doesn't mean it won't kick ass.
I recommend a hot cup of green tea to calm your nerves ;)
My sincere best wishes to all those in the path of Hurricane Rita. May you and your loved ones be safe from harm.
O/R Mapper and Code Generation Resources
DLinq and LINQ Posts
Drinking: Sencha Green Tea