I'm considering spending time learning and using LINQ to SQL but after years of best practices advising NOT to embed SQL I'm having a hard time changing paradigms.
Why does it seem accepted now to embed queries in compiled code? It seems almost a step backwards to me in some ways.
Has anyone had issues with fix query / compile / deploy cycle after switching to LINQ?
I think I still might wait for the finished Entity Framework.
What do you think?
The advantage of Linq to Sql is that it doesn't really embed queries in compiled code - not really. The Linq statement means that your .Net code actually has the logic required to build the Sql statement embedded, not the raw Sql.
It really makes a lot of sense to have .Net code that converts directly to the Sql to execute, rather than a long list of sprocs with associated documentation. The Linq way is much easier to maintain and improve.
I don't think I'd switch an existing project to Linq - really it's a replacement for the entire data-layer and it can change the way all access to that layer is done. Unless you're switching from a very similar model the cost is going to be far too high for any potential gains.
Linq to Sql's real power is in quickly creating new applications - it allows you to very rapidly create the data-layer code.
I undertand your point, this does indeed seem like a bit of a backward step...
Actually I would probably steer away from LINQ to SQL and look more at LINQ to Entities, your entities model your conceptual data model and I personaly feel more comfortable embedding queries agains a conceptual model in my code. The actual physical model is abstracted away from you by an entity framework.
This link (excuse the pun) discusses LINQ to Entities and the Entity Framework: http://msdn.microsoft.com/en-us/library/bb386992.aspx
This is an interesting article discussign the pros and cons of both approaches: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm
Edit Another thought, if you don't want wait for EF, have a look at NHibernate, you can LINQ to that too... See http://www.hookedonlinq.com/LINQToNHibernate.ashx
You need to think of LINQ to SQL as an abstraction above writing SQL directly yourself. If you can get your head around this then you’ve made a step in the right direction. You also need to let go of some long held beliefs such as compiled sprocs are always faster and SQL accounts shouldn’t have data reader / writer privileges.
I’ve found that it’s possible to begin gradually moving existing solutions towards LINQ to SQL so long as there is a clear DAL in place and you’re just changing the implementation without affecting the contract it may have with consuming code. Reference lists are an easy candidate as they’re low impact, read only sets of data. The main thing you need to remain conscious of if retrofitting is potential ambiguous class names if you’ve already hand coded them to model the database.
With the value of hindsight in bringing LINQ to SQL into a large enterprise (since CTP days), I’d do it again in a heartbeat. It’s not perfect and there are issues but there are enormous benefits particularly when it comes to development speed and maintainability. It’s a new paradigm and is definitely, definitely a step forward.
There is an implementation of LINQ to SQL not only for SQL Server databases, so the non-SQL Server developers can also take advantage of using this efficient ORM.
We have already added support for query-level LaodWith( ) and extended the error processing.
Also we plan to support all three inheritance models (TPH, TPT, TPC) and key field generation.
You can find the list of supported databases here
I don't think of it as embedding SQL in your code any more than embedding a Stored Proc name in your code is. More often than not a change to your Proc involves change to your code anyway. For example, you usually need to add a new in/out parameter or update a getter/setter method to reference a new column.
What it does is remove a lot of the leg work of writing twice as much code to align properties and methods in your code with procs and columns in your DB.
Related
I am a young developer and don't really know many different ways to accessing databases and get data out of them. One of the ways I know is to use DataAdaptor with SQLcommand with Stored Procedure provided by database team to connect database and fill the data into DataTable. Then I use the datatable for processing, or bind it to gridview, etc for display purpose.
But when the reviewer reviewed my code, he said datatable is very old fashioned way. He said he rather use objects or something but I have no clue.
So is there better (or modern) way of connecting databases, and get data out of them? This is a generic question and should not really matter with what my program really does.
They were a stupid idea at .NET 1.0 time when the Java world already was using ORM's for years. They were a stupid idea when ADO (not ADO.NET) was released and ORM's were already in use in the Java world already and I used one with Visual Basic (not .NET).
Learn proper OO programming. Anyone using Datasets pretty much shows he has only seen the MS "how to make a UI fast" example and not ever learned trpoper object oriented programming practices.
I would NOT call a 15 years established Technology "modern".
For example, you should KNOW about LINQ. Entity Framework - both are part of the .NET Framework ans that for some time now (since 4.0).
This is not about "Age" it is about knowing what you do. And reading the documentation ONCE. When a "Young cook" only knows pepper he is not a cook, he is a one trick Pony. A "yount" (not Trainee) .NET developer who has no idea about all ways to get data out of the atabase is not a .net developer - because he misses reading the documentation ONCE. Asking about Details is ok - but not having heard of Entity Framework is... well, somoene who never read the documentation.
And again. ORM's are not new. They existe in .NET 1.0 time, they existed in old Visual Basic time.
Your colleague is probably well versed in ORMs like nHibernate and Entity Framework, which provide an object-oriented abstraction over your database.
Object relational mappers perform a lot of the "glue" tasks safely and automatically. Decent enough example of this are database relationships, etc.
In the MVC space, it's common for the objects that are presented to the server to have no information about the underlying data access structure.
I still use DataTable in some very limited situations. I suppose my key concerns are:-
Very generic solution. Not domain specific.
Contrast this with a purpose-built class aimed at performing a specific job.
A lot of coupling, a lot of error checking, or both.
Oftentimes, you'll want to use your DataTable to populate something else. To do this properly, you'll need to check for NULLS, etc, usually with something like:-
string thing = (row["Thing"] == DBNull.Value ) ? string.Empty : (string)thing;
It's onerous, time-consuming and error prone.
Mostly though, it's an artefact from the days when people would pull directly from a DB and blat it on a webpage. Today, there are several layers of abstraction in between with n-tier products, and DataTable is a reasonably poor substitute for the bells and whistles you get from an ORM.
question:
i'm building (or trying to build) a front end for an enterprise level web-app. the existing structure is driven by stored procedures (sql 2008 db). A stored proc is implemented as a class that ultimately handles the execution and the results are returned as an object.
i'm new to this game and would welcome an explanation about how my time would best be served...i read a repository pattern is a best practice, but all of the examples i read implement Entity Framework or Linq, etc..do i need an ORM? why or why not? i'd like to be able to have a maximum performance environment so that users can play with those result sets. thanks in advance
Well, I would suggest deciding on your use cases.
Some of the things that nHibernate / ORM's generally are not good for are:
Batch jobs.
Reporting
So if your work primarily involves either of those then you're best off not wasting your time, that being said there's nothing wrong with having multiple strategies... Building out a domain model is great for simplifying complex business rules, performance is generally very good too... Reporting and batch jobs can be built out separately, there's no reason why the different strategies can't co-exist... I woul however do my best to keep them decoupled...
So if you've got a big hairy business logic layer and it's littered with datasets / data access code and business logic IN your stored procedures then you will likely find it worth your while to invest in an ORM, but consider it a re-factoring step... IE you're improving existing code and making it testable before extending it...
In any case there's no one 'best' answer, the smartest thing I've done at previous companies has been to build new functionality (Test driven of course) in whichever data access pattern that seems to make sense to the functionality... Keep interfaces clean and decoupled... After doing that for awhile it usually becomes obvious which strategy / pattern is best suited for the application overall...
Good luck
Your question is somewhat unclear. Stored Procedures are SQL queries stored on the database which are used to interact with the data. However, it sounds like you already have an existing data access layer (DAL) which uses stored procedures and returns objects to you to play with. If this is the case, I would not throw away the entire data access layer and replace it with EF or any other ORM. Unless the existing DAL isn't working for you for either design or performance reasons, there's no reason to reinvent the wheel.
We're going to be rebuilding one of our sites in .Net. I've read many articles and really like the idea of separating our project into a data access layer (DAL), Business logic layer (BLL), and presentation layer (we're coming from classic ASP so this is a massive step for us). I also really like Linq to SQL.
Since Linq to SQL is aimed at rapid development, is it really possible with Linq to SQL to have a DAL, BLL, and presentation layer? With Linq to SQL would the DAL return the entities or the linq code which could be possibly modified in the BLL? The relationship between the DAL and BLL with Linq to SQL seems to be a fuzzy topic with no consensus - and since this is such a big jump for us I definitely want to have a good game plan before diving into anything.
Typed Datasets seem more equipped for this, but if I can get something similar with Linq I'd go that route.
I'd like to stay away from nHibernate and other 3rd party libraries.
We're building exactly what you described, and we're using L2S to do it. Agreed that the relationship between the DAL and BLL is a bit fuzzy, but we have a distinct BLL and a distinct DAL. All our logic is in the BLL and all data retrieval/modification is done via calls to the DAL (using LINQ calls).
Our app uses no typed datasets. We've built entity classes to represent our objects. Now that I've spent a couple months building part of this, I don't see us (me) ever going back to datasets.
Also, I wouldn't get hung up on L2S being "aimed at rapid development". This makes it sound like a prototyping tool. We're finding it to be an industrial strength tool. This might be contrary to what Microsoft might now be saying about it, since they would rather people use EF.
Randy
I recommend to take one step back and look at your requirements once again.
Do you need real 3 tiers (that is physical deployment to different machines) or just logical partitioning of your application?
I made exactly this mistake on the first big Application I have written. I never needed physical 3 tiers (and will never need) but designed the application that way. The most striking consequence was that I Linq2Sql does not support disconnected Change Tracking on the entities. I used Linq2Sql Entity Base to workaround this limitation, however it violates the concept of Persistence Ignorance very badly (one always knows better afterwards, huh?).
Going real n-tiers has a lot of other implications on application architecture.
You will need message passing, data-transfer objects etc. Linq2SQL is a decent ORM, the tight integration with LINQ provides unique possibilities. Other ORMs will still need some time to catch up here. NHibernate 3.0 is a light at the end of the tunnel here.
Linq2SQL is a great ORM if you have simple data models and can map in a "class per table" manner.
For disconnected change tracking (which you will need if going n-tiers) other ORMs have better support.
And at last:
(we're coming from classic ASP so this
is a massive step for us)
Under these circumstances I'd be especially careful. Switching technologies is often underestimated. Even the smartest programmers on your team will make wrong decisions because they lack experience with the technology. Nonetheless it is important to go new ways and improve your skill set. Those who never fail will never suceed.
I would say L2S is the DAL. L2S + business logic in separate classes becomes a merged DAL+BLL, the DAL side being the L2S runtime, and the L2S-generated code (datacontext, entity classes etc).
You can still easily separate them so that the L2S-generated part, and any extensions to the entities and datacontext are in a separate DLL, and additional business logic in a separate dll/service/etc. However in many cases there is no real need to separate them.
One reason to separate into DAL+BLL when using L2S would be if you foresee that you will move to another data access technology down the road, or if you may be using more than one data access technology. Having a separate DAL with any L2S-specific stuff separate should make it easier to switch out the DAL. If you want to separate DAL+BLL for that reason, the L2S DAL-DLL should expose the entity classes, any derived classes or projection classes, and methods to get entities or collections (List etc), but keep the DataContext internal to the DAL class to avoid having L2S-specific things (L2S queries etc) trickle into the BLL.
JMHO.
Since others mentioned L2S tools, here is a more complete summary of what's out there: http://www.thinqlinq.com/post.aspx/title/linq-tools
IMHO, LINQ to SQL is the best choice available currently. It really makes working with data painless and almost fun. :-) If you are interested in LINQ to SQL, I'd take a look at our PLINQO project. It has some great enhancements to LINQ to SQL to make it a better overall solution.
I think with linq the DAL and BLL concepts are no longer meaningful. So I placed linq classes and
some getters & setters under the 'Domain' folder under the Code (parent) folder. Then I created 'Repository' classes and 'FontEnd' classes.
Given the premise:
There are competent sql programmers
(correlary - writing sql queries are not an issue)
There are competent application developers
(correlary - there is simple/strong/flexible architecture for handling connections and simple queries from code)
Why do people use linq to sql?
There is overhead added to each transaction
There is strong likelihood of performance loss for moderate-complex calculations (DBs are made for processing sets and calculations and had teams of engineers working out optimization - why mess with this?)
There is loss of flexibility (if you want to add another ui (non .NET app) or access method, you either have to put the queries back in the db or make a separate data access layer)
There is loss of security by not having a centralized control of write/update/read on db (for example, a record has changed - if you allow applications to use linq to sql to update, then you cannot prove which application changed it or what instance of an application changed it)
I keep seeing questions about linq to sql and am wondering if I'm missing something.
I keep seeing questions about linq to sql and am wondering if I'm missing something.
It's not that you're missing something. It's that you have something most shops don't have:
There are competent sql programmers
Additionally, in your shop those competent sql programmers prefer to write sql.
Here's a point by point response:
There is overhead added to each transaction
Generally true. This can be avoided by translating the queries before they are needed to run using CompiledQuery for many (but not all!) scenarios.
There is strong likelihood of performance loss for moderate-complex calculations (DBs are made for processing sets and calculations and had teams of engineers working out optimization - why mess with this?)
Either you're writing linq, which is translated to sql, and then a plan is generated from the optimizer - or your writing sql from which a plan is generated by the optimizer. In both cases you are telling the machine what you want and it is supposed to figure out how to do it. Are you suggesting that subverting the optimizer by using query hints is a good practice? Many competent sql programmers will disagree with that suggestion.
There is loss of flexibility (if you want to add another ui (non .NET app) or access method, you either have to put the queries back in the db or make a separate data access layer)
A lot of people using linq are already SOA. The linq lives in a service. The non .NET app calls the service. Bada-bing bada-boom.
There is loss of security by not having a centralized control of write/update/read on db (for example, a record has changed - if you allow applications to use linq to sql to update, then you cannot prove which application changed it or what instance of an application changed it)
This is simply not true. You prove which application is connected and issuing sql commands the same way you prove which application is connected and calling a sproc.
Let me list you a few points:
There are small software companies or mid-sized companies who develop their software in-house who might rather focus on getting many application developers than getting a freelancer DB developer or even permanently hire one.
In most cases the overhead is a non-issue either due to the amount of data to be processed or due to the low traffic. Besides, when used properly, LINQ to SQL can perform as fast as most SQL queries + the associated .net code.
Many companies just stick with the Microsoft stack and they can only enjoy the integration. Some other company develops using SOA there's just no problem. The others aren't forced to choose LINQ-to-SQL and if they make that choice is their problem how to integrate it. Nobody ever said LINQ-to-SQL is a silver bullet :)
I believe security is gained with LINQ-to-SQL because I've bumped across lots of SQL queries taking in unescaped data with string concatenation etc and explaining the whole parametrized query idea has never been easy. Besides since all queries are eventually translated into SQL, unless the tracking issue you describe would happen via a stored procedure, there're again no problems at all.
I also believe your question can be posed more generally to address all ORMs and not just LINQ-to-SQL, and still most of what I said would hold true.
The problem is that it is very rare for somewhere to have a competent SQL developer who likes writing SQL and wouldn't rather be doing something else. I would consider myself competent in SQL, I used to do all my data access layers with stored procs or parametrized queries. Trouble is that it takes ages and is dull. I'd rather be writing great applications than messing around with data access layers that essentially have a select, insert, update and delete SQL statement(or proc) repeated dozens of times for each data object.
Linq-to-SQL takes away some of the repetitive nature. It has a tool to auto generate you business objects from your database schema, and it gives you a nice integrated query language that is compile time type verified and is in your code (Stored procs are a pain to source control neatly)
I can write a DAL in Linq-to-sql several times faster than I can using plain SQL, stored procs or parametrized queries.
If you want to maintain the use of stored procs both linq-to-sql and the EF both support the use of stored procs for all their data access, you just have to set up the appropriate mappings. So, you can still use your stored procs to log details and implement security if you want. We tend to opt for using windows auth, and use that to restrict access to each table for the various users, then we have a bunch of triggers on the tables that track details for audit purposes.
Two things I will quickly note is that firstly, the entity framework seems to be getting more support from MS at the moment, and I suspect that will be considered the kind of default standard for the future in preference to linq-to-sql. Secondly, in .Net 3.5 the EF and linq-to-sql do not have very good support for n-tier disconnected apps. In both of them you kind of have to muck around with either serializing data contexts across your disconnected tiers, or manually detach and re-attach your data objects. This is much improved in the .net 4.0 though. Just something to consider depending on which version you have available to you.
Existing question/answers in the same vein/spirit:
Doesn't Linq to SQL miss the point? Aren't ORM-mappers (SubSonic, etc.) sub-optimal solutions?
LINQ-to-SQL vs stored procedures?
What's wrong with Linq to SQL?
Why do I need Stored Procedures when I have LINQ to SQL
If using LINQ to SQL is there any good reason to learn SQL queries/syntax anymore?
https://stackoverflow.com/questions/216569/are-the-days-of-the-stored-procedure-numbered
I personally believe there's no right or wrong answer. It depends on what you're developing and how you're developing it. If you need razor-sharp performance, have an overly-complex data model, etc... skip the abstraction. If you feel the abstraction speeds up your development time, like the idea of capturing all application logic in a single codebase, etc... use it.
For me, it takes a lot less time to write linq to sql code than it does to write a bunch of stored procedures. That's especially true when the design isn't finished, in that case I don't yet know how much of the work I want to do on C# objects, and how much I want to do in SQL.
So, I can skip building datasets, I don't have to click click click to add queries, basically, linq to sql means I can change my code in less time.
Also, as a big fan of Haskell, I can write lots of functional-style code with linq to sql and it just works.
I'm not saying this is an ideal solution or even a great example (it was the result of a high level constraint on the architecture, not something we necessarily would have chosen from scratch), but...
I worked on an app where the code was completely isolated from the database except through a set of exposed stored procs. The code could not "know" anything about the database schema except was was returned from the stored procs.
While this isn't that unusual and it isn't too hard to write a DAL using ADO or whatever, I decided to try out Linq to Sql, even though it wouldn't be using it for its real intended purpose and wouldn't use most of the features. Turns out it was a great decision.
I created the Linq to Sql class, dragged the stored procs from server explorer onto the right side of the designer, then... Wait, there is no then. I was pretty much done.
Linq created strongly typed methods for each stored proc. For the procs that returned rows of data, Linq automatically created a class for the items in each row and returned a List<generatedClass> for them. I wrapped the calls themselves in a lightweight public DAL class that did some verification and some automatic parameter setting and I was done. I wrote a business object class and mapped the dynamically generated Linq class objects to the business object (did this by hand, but it isn't hard to do or maintain).
The program is now immune to any schema change that doesn't affect the stored procedure signatures. If the signatures do change, we just drag off the old proc from the design and drag it back to regenerate the code. A few passes through the unit tests to make changes (which usually don't go higher than the public DAL interface) and it's done. Things upstream of the DAL use Linq to Objects techniques to select, filter, and sort data that isn't in the right format straight from the stored proc calls.
We have some excellent DBAs writing the stored procedures and an entirely different group writing the other code, so maybe it is a good example of why (and how) you can use LINQ in the scenario you describe.
Some handy features are the debugger picking up sytax errors in your query, compared to writing SQL statements as strings. Mistakes that wont get picked up until runtime.
Plus I find LINQ statements easier to read than SQL.
It may be a case of convenience triumphing over performance. If you're programming at Facebook levels of uber-performance then you might think about every clock cycle but the simple truth is that the majority of applications don't need this attention and benefit from efficiencies in code maintenance and dev time (100k contractor vs. another $erver).
That said, there's a case for outsourcing as much of the query processing from the DB box in very high scale systems, else the DB is the bottle neck and you need to shard or re-architect down the line. Costly.
I think its fair to say that LINQ will scale better/easier both in terms of servers and from many core in that your LINQ codebase will get m-core for 'free' as soon as MS release C# 4.0.
I do see your point in asking and as a non-ASP.NET dev just beginning a www project for the first time, I can't see the point of 80% of ASP.NET (themes, controls etc.) - it seems I need to learn more and code more than the HTML itself! -- again, I'm sure there's an good reason for it all.
--- I haven't got the 50 pts to comment on the post I want to so I'm doing it here ---
David B suggests that writing some SQL is all there is to getting the most out of SQL Server and that using query hints is the steering mechanism. The same task can be achieved in many different ways in SQL and many with 1000s of times the performance gain. I suggest reading Inside T-SQL Querying (Itzik Ben Gan). Over and over, Itzik shows how to rethink the query and use new commands to shrink the logical reads sometimes from thousands into less than ten.
For very simple queries, the overhead of an extra layer adds to the roundtrip cost. For somewhat more complex queries in normal 'business app' scenarios, the optimizations done by the Linq-to-SQL expression->sql translation magic can often save a lot.
As an example, I recently did a 1:1 translation of a customer-supplied 1400+ (!) line stored proc to L2S. Not only did it go from 1400 lines of SQL to 500 lines of much more readable, strongly typed, and commented code. It also started hitting the database with an average of ~1500 reads instead of ~30k reads. This is before I even started looking at db-side optimizations - that saving is something I can 100% attribute to L2S's ability to eliminate predicates that can be evaluated client-side.
simple answer, there are two approaches: create exquisite Rube Goldberg contraptions, or just get the job done in a simple way. Many devs lean towards the former.
Developers get bored easily, and would often personally enjoy doing things a harder way that seems to provide a certain intellectual beauty. Are you developing an app or writing a PhD? As my msft director used to yell in the hallways, "I don't want another research project!"
please repeat after me (min 3x)
there is no silver bullet
I will not use a technology just because its the latest thing from msft
I will not use something just to get it on my resume
Not only are their competent SQL coders, any decent app programmer, especially LOB apps, should write intermediate SQL. If you don't know any SQL and are writing LINQ to SQL, how are you going to debug your data calls? How are you going to profile them to fix bottlenecks?
We're trying out LINQ to SQL and I think there are major issues with it, such as:
There is no simple way to return the query results to another object. This in itself seems insane. Microsoft created the var anonymous datatype, and recommends using it, but there is no way to move this data out of your local method, hence the oo paradigm breaks if you have to use the data in the same function that retrieved it.
Tables are NOT objects. Study up on 3rd normal form etc. Relational databases are for storing data, not using it. I don't want to be restricted or encouraged to use my tables as objects. The data I retrieve from the database will very often be joins of multiple tables, and may include SQL casts, functions, operators, etc.
There is no performance gain, and a slight loss
Now I have way more code to worry about. There are the dbml files and still a DAL to actually write the LINQ. Yes, lots of it is machine-generated, that doesn't mean its not there, its something else that can go wrong (i.e. your dbml files, etc.).
Now that I've given the background, I will attempt to answer you actual question, why do people use LINQ To SQL:
Its the latest thing from Microsoft and I want it on my resume.
Msft has convinced managers/execs that it will decrease coding time
Developers hate SQL. (no good dev environment or debugging except manually--it would be nice to have better intellisense to a sql tool.)
I encourage people not to jump on the bandwagon just because everyone else is, learn enough to put it on your resume, be willing to use it if forced to, but try and really understand the pros and cons first.
I have been playing with some LINQ ORM (LINQ directly to SQL) and I have to admit I like its expressive powers . For small utility-like apps, It also works quite fast: dropping a SQL server on some surface and you're set to linq away.
For larger apps however, the DAL never was that big of an issue to me to setup, nor maintain, and more often than not, once it was set, all the programming was not happening there anyway...
My, honest - I am an ORM newbie - question : what is the big advantage of ORM over writing a decent DAL by hand?
(seems like a double, couldn't find it though)
UPDATE : OK its a double :-) I found it myself eventually :
ORM vs Handcoded Data Access Layer
Strong-typing
No need to write the DAL yourself => time savings
No need to write SQL code yourself =>
less error-prone
I've used Hibernate in the past to dynamically create quite complex queries. The logic involved to create the appropriate SQL would have been very time-consuming to implement, compared with the logic to build the appropriate Criteria. Additionally, Hibernate knew how to work with various different databases, so I didn't need to put any of that logic in our code. We had to test against different databases of course, and I needed to write an extension to handle "like" queries appropriately, but then it ran against SQL Server, Oracle and HSqldb (for testing) with no issues.
There's also the fact that it's more code you don't have to write, which is always a nice thing :) I can't say I've used LINQ to SQL in anything big, but where I've used it for a "quick and dirty" web-site (very small, rarely updated, little benefit from full layer abstraction) it was lovely.
I used JPA in a project, and at first I was extremely impressed. Gosh it saved me all that time writing SQL! Gradually, however, I became a bit disenchanted.
Difficulty defining tables without surrogate keys. Sometimes we need tables that don't have surrogate keys. Sometimes we want a multicolumn primary key. TopLink had difficulties with that.
Forced datastructure relationships. JPA uses annotations to describe the relationship between a field and the container or referencing class. While this may seem great at first site, what do you do when you reference the objects differently in the application? Say for example, you need just specific objects that reference specific records based on some specific criteria (and it needs to be high-performance with no unnecessary object allocation or record retrieval). The effort to modify Entity classes will almost always exceed the effort that would have existed had you never used JPA in the first place (assuming you are at all successful getting JPA to do what you want).
Caching. JPA defines the notion of caches for your objects. It must be remembered that the database has its own cache, typically optimized around minimizing disk reads. Now you're caching your data twice (ignoring the uncollected GC heap). How this can be an advantage is beyond me.
Data != Objects. For high-performance applications, the retrieval of data from the DB must be done very efficiently. Forcing object creation is not always a good thing. For example, sometimes you may want arrays of primitives. This is about 30 minutes of work for an experienced programmer working with straight JDBC.
Performance, debugging.
It is much more difficult to gauge the performance of an application with complex things going on in the (sub-optimal, autogenerated) caching subsystem, further straining project resources and budgets.
Most developers don't really understand the impedence mismatch problem that has always existed when mapping objects to tables. This fact ensures that JPA and friends will probably enjoy considerable (cough cough) success for the forseeable future.
Well, for me it is a lot about not having to reinvent/recreate the wheel each time I need to implement a new domain model. It is simply a lot more efficient to use for instance nHibernate (my ORM of choice) for creating, using and maintaining the data access layer.
You don't specify exactly how you build your DAL, but for me I used to spend quite some time doing the same stuff over and over again. I used to start with the database model and work my way up from there, creating stored procedures etc. Even if I sometimes used little tools to generate parts of the setup, it was a lot of repetitive coding.
Nowadays I start with the domain. I model it in UML, and for most of the time I'm able to generate everything from that model, including the database schema. It need a few tweaks here and there, but with my current setup I get 95% of the job with the data access done in no time at all. The time I save I can use to fine tune the parts that need tuning. I seldom need to write any SQL statements.
That's my two cents. :-)
Portability between different db vendors.
My, honest - i am an ORM newbie - question : what is the big advance of ORM over writing a decent DAL by hand?
Not all programmers are willing or even capable of writing "a decent DAL". Those who can't or get scared from the mere thought of it, find LINQ or any other ORM a blessing.
I personally use LINQ to manipulate collections in the code because of its expressiveness. It offers a very compact and transparent way to perform some common tasks on collections directly in code.
LINQ will stop being useful to you when you will want to create very specific and optimized queries by hand. Then you are likely to get a mixture of LINQ queries intermingled with custom stored procedures wired into it. Because of this considerations, I decided against LINQ to SQL in my current project (since I have a decent (imho) DAL layer). But I'm sure LINW will do just fine for simple sites like maybe your blog (or SO for that matter).
With LINQ/ORM there may also be a consideration of lagging for high traffic sites (since each incoming query will have to be compiled all over again). Though I have to admit I do not see any performance issues on SO.
You can also consider waiting for the Entity Framework v2. It should be more powerful than LINQ (and hopefully not that bad as v1 (according to some people)).
Transparent persistence - changes get saved (and cascaded) without you having to call Save(). At first glance this seems like a nightmare, but once you get used to working with it rather than against it, your domain code can be freed of persistence concerns almost completely. I don't know of any ORM other than Hibernate / NHibernate that does this, though there might be some...
The best way to answer the question is to understand exactly what libraries like Hibernate are actually accomplishing on your behalf. Most of the time abstractions exist for a reason, often to make certain problems less complex, or in the case Hibernate is almost a DSL for expression certain persistance concepts in a simple terse manner.
One can easily change the fetch strategy for collections by changing an annotation rather than writing up lots of code.
Hibernate and Linq are proven and tested by many, there is little chance you can achieve this quality without lots of work.
Hibernate addresses many features that would take you months and years to code.
Also, while the JPA documentation says that composite keys are supported, it can get very (very) tricky quickly. You can easily spend hours (days?) trying to get something quite simple working. If JPA really makes things simpler then developers should be freed from thinking too much about these details. It doesn't, and we are left with having to understand two levels of abstraction, the ORM (JPA) and JDBC. For my current project I'm using a very simple implementation that uses a package protected static get "constructor" that takes a ResultSet and returns an Object. This is about 4 lines of code per class, plus one line of code for each field. It's simple, high-performance, and quite effective, and I retain total control. If I need to access objects differently I can add another method that reads different fields (leaving the others null, for example). I don't require a spec that tells me "how ORMs must (!) be done". If I require caching for that class, I can implement it precisely as required.
I have used Linq, I found it very useful. I saves a lot of your time writing data access code. But for large applications you need more than DAL, for them you can easily extent classes created by it. Believe me, it really improves your productivity.