undefined | Better HN

0 pointshackerfromthefu5y ago0 comments

Well as someone with 25 years SQL experience, I generally will still use LINQ for 90% of db access code in business style applications, for very important reasons beyond those mentioned, like

- They may realise value in having a compiler provide guarantees, as a bonus immediately in a tight feedback look while editing code as well as on compilation

- They have favour expressive languages with robust error handling, integrated IDE and VC etc

- They may want to reduce the number of moving parts

These are all along the themes of a) delivering results faster, and b) improving the maintenance lifecycle of systems - unlike those parts of the industry that don't really plan to maintain their systems and instead just wanna do rewrites in the latest hotness which is usually a hot mess from a long term maintainability perspective.

0 comments

2 comments · 1 top-level

fhars5y ago· 1 in thread

But then LINQ is in many ways conceptually closer to directly using SQL than to using a classical ORM.

hackerfromthefuOP5y ago

Sorry my wording could have been more explicit!

Generally, use of LINQ in the context of DB access is done hand in hand with an ORM, such as Entity Framework, NHibernate etc, and this is how I meant it.

j / k navigate · click thread line to collapse