|
Stop dev on Linq-To-Sql??
If it's not broken, fix it until it is
|
|
|
|
|
It has not been updated or improved since the .NET 3.5 release. That was 7 years ago.
|
|
|
|
|
Maybe they simply got it right back then
If it's not broken, fix it until it is
|
|
|
|
|
No harm in using it, just that you may miss out on new optimizations and features available in newer releases of Entity Framework, specially those that take advantage of new functionality in recent versions of SQL Server.
|
|
|
|
|
|
Still using raw sql and datareaders. No ORM, every query hand-crafted.
Works as great as it did ten years ago
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Even (nearly) fifteen years ago.
modified 16-Feb-16 14:40pm.
|
|
|
|
|
..if possible, I try to remain SQL92 compliant. Works on most systems, from Sql Server to SQLite.
It's good to have standards
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
Prior to 2002 and .net, I was using PL/SQL embedded in C.
ADO.net has allowed me to work with many more database systems.
|
|
|
|
|
PIEBALDconsult wrote: Prior to 2002 and .net, I was using PL/SQL embedded in C. Oracle 7.
Yes, good times.
PIEBALDconsult wrote: ADO.net has allowed me to work with many more database systems. [Dance] I can't comment on C, but it is a lot simpeler than having "some" ODBC connection in Delphi. And I am not missing the "begin" and "end" keywords around every method
..not much at least.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: every query hand-crafted
You have got to be joking, you type out every CRUD query/stored proc? What a monumental waste of effort that must be.
I refuse to allow any commercial ORMs on site but have written our own, sort of. I have not hand coded a CRUD proc for over 20 years.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
That's because the concept of "CRUD" is nonsense. Lucrative nonsense for tool merchants and their fear-mongers.
|
|
|
|
|
You are going to have to elaborate on that a little, as it is the statement does not seem to make sense.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: You have got to be joking, you type out every CRUD query/stored proc? Rather quick with templates and intellisense.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I want to use one of the 3 ORM options (NHibernate, EntityFramework and LinqToSql) in my application which one is the better? and what is the advantages of it over than others?
|
|
|
|
|
If I were developing the application, I'd avoid using an ORM altogether. I don't like the lack of fine grained control they present and the fact that they largely constrain me to doing things in certain prescribed ways - as soon as I want to do something out of the ordinary, things become a lot harder.
Now, as to your question - only you can answer that. We don't know what your application is, what it does, how it scales, etc. You might as well go to your local swimming baths and say "I want to buy a car. A Mercedes, a Volkswagen or a Ford. Which is better and why?"
This space for rent
|
|
|
|
|
My Application is a an MVC web application
|
|
|
|
|
So you've said you want the red car.
That tells you nothing about your application other than the platform you want it to run on. In order for YOU to answer your question, you are going to have to actually break down your requirements. Never, ever start from the point of "I want to use this technology". Instead, you start from the point of view, "I have these requirements X, Y and Z. What technology will best serve those requirements and won't constrain me to use only A, B and C?" In other words, you are asking the wrong questions. Go back and start again.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: So you've said you want the red car.
Or...
"I want to cruise up the coast to Santa Barbara with my girlfriend. My girlfriend never packs light. Should I drive a Mack truck or a Peterbilt? A cab-over or a conventional?"
|
|
|
|
|
Model T versus a 2016 whatever. I'll take the 2016 whatever, thank you.
|
|
|
|
|
My application is a MVC
Good question.
I don't have an answer, but, I do have the same question.
I have only worked with small MVC projects, and most of them, use a "different way of doing things" that an O.R.M. I have read some people have made custom MVC (or MVP, MVVM, etc) and ORM, hybrids, but, dont have a web link right now.
I made a custom, N-Tier (3-Tier) and Entity ORM library Hybrid for some customer. I actually wanted to avoid to "reinvent the wheel", and wanted to use either Microsoft Entity Framework or NHibernate, Subsonic or others.
For the framework part, Microsoft MVC and MVP didnt exist or was the first version, same thing goes for Linq,and LinqToSQL.
MS was changing from VS2005 to VS2008, and the other frameworks (mostly Open Source), where also changing, some where deprecating the VS2005 version, while the changes on the VS2010, didn't have enough documentation, altought I read on the web, at the time, that where good.
And, for another reason, the customer need it, the software on MySQL and Firebird (Interbase), not MS SQL Server. Myself, I required to be available on PostgreSQL.
The native MS Entity and other existing didnt have finished support for the other databases, at that time, they do now.
The paid ORM libraries like Telerik Open Access, and others, cannt be affored by my customer, or myself.
So, I ended having to reinvent the wheel.
Today, many of my other customers, still have VS2005, VS2008, VS2010, and are not interested to migrate to newer versions.
Now, I have two scenarios.
For new projects, I need to find a way to use MVC/MVP with other databases that are not MS SQL Server, some of them already support MS Entity, Linq or LinqToSQL, other doesnt.
For legacy projects, some of them can be redone, by migrating as new projects, others, I need to find a way to merge to a MVC or MVP framework.
I will read the others answers, to see if they can be useful for my software projects.
Cheers.
Mark Ramirez
mail dot umlcat (a) gee mail dot com
|
|
|
|
|
I went through the OR/M craze for a few years too before switching back to standard DataLayer models. The biggest issue for us is that ORMs have direct access to tables and generate Non-optimized SQL code that can be difficult to monitor and tune and as soon as you want to do something out of the ordinary, the complexity skyrockets.
We have since moved back to the model where all access to data routes through Stored Procedures, which restrict access, creates audit trails, and santitizes input.
|
|
|
|
|
Good point. Have the same issue.
I ended making a custom sort of N-Tier Layered and Entity-like hybrid ORM Library.
You may like to read a previous answer of this scenario, in a previous answer, on this same page ...
|
|
|
|
|
EntityFramework allows the use of views and stored procedures in place of tables. I use stored procedures for create, update and delete, and use views for retrieve. When I alter a table, it is very simple to update the application from the database. The application itself is just the server side of a web API, which works without my having to specify individual column names, until I get to the actual use of the data in the web client.
I will say that I also don't like the sometimes buggy black box that ORM tends to be. I wrote a PHP version of my server application in which all of the tables and column names are specified in one, simple class file, and all of the routing is specified in one other simple file. The code is fairly transparent and, except for those two files, it is unnecessary to make changes to it to adapt to entirely different database structures, but I can easily do so, if necessary. The flexibility of PHP allowed me to do all that an ORM would do without an ORM black box.
|
|
|
|
|