is it necessary to use LINQ for sql purposes in MVC ? can't we use traditional queries like:
Select name from tbl where id = 2;
instead of LINQ ? and why linq in any case ?
ASP.NET MVC in no way restricts your choice of data access technology. In fact, model binding works with objects, and MVC has no idea whether your objects represent some database or not.
Besides, if you were to use LINQ at all, you would do best to use Entity Framework (a.k.a. LINQ to Entities) and not LINQ to SQL, which is much more limited.
Linq to SQL, EntityFramework, nHibernate - are ORM (Object-relational mapping) tools. ORM represent database objects as standard .NET classes.
Raw SQL can be used, when you are inserting a lot of data, and you need a good performance. In all other cases you should to use ORM.
And if you decide to use ORM, I advise you to use EntityFramework; it's more powerful than LINQ to SQL.
You don't need to use linq at all. I usually use dapper.net for my data layer, mapping SQL queries to objects. It's personal preference.
You are not obliged to use Entities Framework, as you are not obliged to use anything in particular.
Microsoft strongly suggests using the Entities Framework because it is an ORM integrating very easily with the whole Microsoft ecosystem, using the LINQ query language which is integrated in the .NET languages specification. This integration happens through the Linq to Entities query language and the respective tools provided in Visual Studio.
As you will see, Entities Framework (as every other ORM) has the overhead of the learning but in my opinion, it totally pays you back as using an ORM leads to faster development and more maintainable source code. I would strongly suggest using an ORM (it has many advantages) and I suppose since you are already familiar with Microsoft ecosystem, Entities Framework would be the best choice.
Hope I helped!
Well, if you want to use this style of queries you can use stored procedures this is to close to the normal query, just and a Linq-to-SQL file into your project and drag and drop you stored procedures then you can use them like methods and this is a link http://msdn.microsoft.com/en-us/library/bb386946.aspx
Note that Linq-to-SQL is integrated only with SQL Server
No, you do not have to use LINQ at all, or any other ORM frameworks, you an work directly against a database.
In .Net this is typically done using ADO.Net, for example using the System.Data.SQL namespace.
See code examples and official documentation here
Related
I would like to have statically typed LINQ expressions that produce SQL to be executed on the database. Unfortunately it seems entity framework core is very limited with regards to union and group by. Is it possible to use another library, e.g. LINQ-to-SQL purely for querying, that uses the statically typed entity classes we already have rather than hand-crafting SQL?
I've settled for using LINQ to DB thanks to this comment.
We're using the same entity classes we use for entity framework for the queries, and to ensure the table names are correct we use the C# nameof operator, e.g. nameof(EFContext.UserTasks). This should allow us to be fairly sure our queries still work even after renaming properties/tables.
While researching about the clean architecture of .NET Core, I understand that only Entity Framework is being used.
I wanted to know whether we can use raw SQL queries by making a connection to SQL with connection strings.
Clean architecture doesn't restricts you to entity frame work. You can also look into micro ORM e.g. Dapper which can be used to write sql queries. It's very powerful and gives you many out of box capabilities e.g. mapping. Infact if you don't want full ORM functionality Dapper is recommended in Microsoft docs.
Dapper
Dapper for read queries
I have an object model that I want to store using an embedded database. I have so far been looking at db4o, NHibernate to SQLCE (w/ linq), and RavenDB. This would be used in a desktop C# application.
The key features I am looking to leverage are: Linq or similar for queries (no SQL or HQL), Embedded data engine, pocos, poco first model, no install (no registry or similar)
Can any one suggest one? Are the three I am looking at the best choices? Are there other options? Of the three, can anyone recommend one over the other?
Thanks
Well the three suggested databases are very different in their nature. SQLCE with Hibernate as RDBMS with a ORM, db4o as object database and RavenDB as document database. Each of them has its strengths.
SQL CE & NHibernate-Combo
The good:
Extremely good support in tooling, the knowledge and a big community is there
Easy to upgrage to MS SQL servers
Extrem good reporting support
The power of SQL
The bad:
Needs mapping
The mapping between the OO and relational world is not easy and can lead to issues with complex models.
RavenDB
The good:
Doesn't need any mapping
Easy to use
Powerful indexing
JSON & HTTP access
The bad:
If your domain doesn't fit to a document-oriented approach, it will be quite painful
It does not support the .NET Framework Client Profile (which is of particular importance as the OP's question is concerning embedded databases)
db4o
The good:
Doesn't need any mapping
Easy to use
The storage model is close the object-model. This also works for very complex models.
-
The bad:
Tooling support is weak.
Afaik all three support LINQ and POCO-first approach. However since NHibernate & SQL CE still need tons of mapping its not as friction free as it could be.
I think if your focus is on POCO first, LINQ-support, ebedded usage and easy to use, I would try RaveDB or db4o.
If your focus is on 'safety', community-knowledge, tool-support and reporting I would go with NHibernate and SQL CE.
Firebird is a terrific embedded database which has long supported all the modern features of an enterprise database:
ANSI SQL
ACID
Stored procedures
Triggers
You can get the .NET provider (last updated May 24th according to the site) and it supports Entity Framework and Linq.
See this question. For LINQ support, check out DbLinq, or since you already intend to use NHibernate you can use NHibernate's own LINQ provider.
We have been suggested to use NHibernate for our project. But the point is our application will only be retrieving the data from the database so are there any benefits of using NHibernate in this scenario?
One more thing, what is the query execution plan in NHIbernate does it support something like prepared statements or the so called pre complied statements.?
I agree to the answers above, but there is one more reason for using nhibernate: Your completely independend of the underlaying database system. You can switch from mysql to oracle and the only thing you have to do, is to change the settings. the access to the database stays exactly the same.
NHibernate is useful is you need to map data from a database table into a .NET class. Even if you're only doing select queries, it still might be useful if you need to pass the data objects to a client tier (web page, desktop app, etc.) for display. Working with plain objects can be easier than working with a DataSet or other ADO.NET data class in a presentation layer.
NHibernate does have the ability to parse/pre-compile queries if you put them in the mapping file.
The benefit for using NHibernate in a read only scenario is that you would not need to map the results of queries back to .net objects as the runtime would do this for you. Also, it provides a more object oriented query syntax (you can also use LINQ), and you can take advantage of lazy loading.
I don't believe NHibernate can use prepared statements unless you are having it call stored procedures.
I find I can do more with NHibernate, and even Castle than with the Linq to Entities, or linq to SQL.
Am I crazy?
No you're not crazy. nHibernate is a full OR Mapper, Linq to SQL and Linq to Entities don't implement everything you'd expect from an OR mapper and targeted at a slightly different group of developers.
But don't let that put you off linq though. Linq is still a pretty good idea.. Try Linq to nHibernate :-)
The big drawbacks to NHibernate, Castle, etc., is that they're not exactly light-weight (especially NHibernate.)
Linq to SQL is good for a light-weight, limited use ORM.
I've used both NHibernate and LINQ to SQL. From my point of view it depends on the project, if I need something quick, I would choose L2S, it's so simple to create the dbml mapping and start using it. If I'm developing a more highlevel enterprise solution I would go for the tried and trusted ORM - NHibernate, I find the logging & transaction features simple to use.
LINQ to SQL has a relatively short learning curve, NHibernate has a much steeper learning curve.
LINQ to SQL only supports SQL Server, so if you've an Oracle database then the decision is already made - NHibernate.
I'd recommend checking out http://www.summerofnhibernate.com/ for excellent screencasts on learning NHibernate.
One thing to bear in mind is that NHibernate can be an absolute pig to configure - especially since its based mainly on XML config files because of its roots as the original Hibernate.
Fluent NHibernate goes some way to making this less painful.
Linq certainly though fits in with the general 'way' in which .NET works.
Blockquote Linq certainly though fits in with the general 'way' in which .NET works
Yikes, this kind of sentiment scares me. The RAD stuff built into .net is NOT how dot net works, it's just a tool set for getting prototypes up. .NET allows us to do full DDD applications, w/ high levels of cohesion, seperations of concerns, and allows us to write decoupled code, despite all the attemps ms makes to couple things. I would strongly disagree that .net likes to be coupled, certian tools like to be coupled, i'll include linq to sql in this fray. linq to sql destroys the idea of having a seperate domain model. I cringe at the thought of using my database schema as the underlying model objects. Proper ORM tools should allow us to model our domain first, then link our relational database to these models. NOT the other way around.
I have not tried the Entity Framework, but I definitely would recommend NHibernate over Linq to SQL; The biggest reason I can give is just the control. Linq to SQL likes to have a lot more control over everything, loading the object and maintaining all kinds of tracking information about the object. If you serialize/deserialize, the tracking information can be lost and strange things can happen when saving it again. NHibernate works more as a repository should - You hand it whatever object you want (that you have configured it to understand, of course), and it puts it away in the database, regardless of what you've done with it.