So I have to make a asp.net project with SQL Server database, the problem is that I have to do it without any ORM-with a specific DB controller and I have always used the Entity Framework which IS an ORM.
I have no idea from where to begin. How do I collect the data and send it the controller with the html.helpers and how to structure the db controller?
I am not allowed to use Linq either just SQL. As much as I can see from the others questions I should use the SQL command class but its not explained structurally.
What I am asking here is just for the basics.How do I get it from the html helper to the database without ORM and what will I need for that as clases and models,how to relate them and if possible for a simple example.
As you mentioned, you can use "classic" SQL commands with ADO.NET. Here is a good example:
Using ASP.Net MVC with Classic ADO.Net
Another way, and in my opinion a very fast and convenient way, is to use the Dapper framework.
I would recommend you to use Dapper with Stored Procedures. It's a good trade-off between ORM (like Entity Framework) and classical SQL commands. I can show you an example if you give me a business case.
Related
I have a .NET Core 3.1 Web API project and I have an existing MS SQL database filled with data.
In my project I need to fetch the data from the database and to return it as results via the API endpoints. I already have the SQL queries for fetching the data in the format:
SELECT <fields>
FROM <table>
WHERE <condition>
And I wonder, what is the best way to get to fetch the data from the database and in the same time to be able to maximum reuse the SQL code that I already have.
I was considering options like:
using Entity Framework Core as a framework (but then, I already have the SQL code and I feel that using the entities with LINQ queries will only result with repetitive work, as I will have to translate my SQL queries into the LINQ queries);
using StoredProcedures and somehow call them (so that I can copy paste my SQL code inside of the procedures and on that way to maximum reuse them). Still I am not sure what is the best way to call / write stored procedures, do I need to use any framework;
using some combined approach, where I will actually use the StoredProcedures but I will call them via Entity Framework Core;
The above points were some conclusions based on my research, as I am not experiences with .NET Core development in general. So any advices will be helpful.
I would suggest having a look at Dapper. It's a Micro-ORM that easily enables you to query your database with SQL, and then mapping the result to .NET objects.
I'm a very beginner in .NET and now I'm developing a little project (web API) using NancyFX framework. In my project, I need to use SQL database for some very basic tasks like storing registered users' details or getting some user information. I'd like to know what is the most popular, convenient and modern way of using SQL in .NET for beginners? I mean, should I use LINQ or just pure SQLClient functionality or are there any good libraries for working with SQL on .NET? I've tried to implement LINQ to SQL pattern but ended up with huge chunks of unused auto generated code and even bigger mess in my head...
For a framework to communicate with you're database I would recommend using Entity framework, its very convenient and easy and has the Code first approach which you should read about.
More over i suggest you follow the repository pattern,
https://msdn.microsoft.com/en-us/library/ff649690.aspx
This basically means - each object you save in the db, will have a repository which will contain all the object of its kind and that will be you're entry point to reading/inserting/updatibg/and deleting rows from the db, while abstracting away all details of implementation - in our case I recommend entity framework as I mentioned before.
Good luck
I have gone through an article of using EntityConnection, EntityCommands for executing Entity sql queries. But I was unable to understand that Why are we using Entity sql? Why not directly using the Classes and objects for processing CRUD operations on database?
Or If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
Is there any performance difference or something else?
I have already gone through the page http://msdn.microsoft.com/en-us/library/bb738573.aspx. But I want answer in a more simpler way. Can you please answer me?
Thanks
Why not directly using the Classes and objects for processing CRUD operations on database?
That is (should be) the way for almost all operations. But sometimes there is a need for accessing the db more directly and precisely.
If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
E-SQL will still let you work with entities (instead of Rows). This is much easier and more powerful, consider inheritance for example.
E-SQL is also supposed to be independent of the actual database, ie the same for Oracle etc. I have no experience with this yet.
Is there any performance difference or something else?
It can be used to improve performance, yes. But not automatically.
The main difference
SQL is database dependent query language working on storage (relational) objects - tables / rows
ESQL is database independent query language working on conceptual (EDMX) objects - entities
ESQL was created prior to LINQ. In some scenarios ESQL offers more functionality than LINQ.
When I last worked in programming, we were trying to move away from DataReaders and the traditional ADO.NET API toward Object Relational Mapping (ORM).
To do this, we generated a DataContext of our DB via sqlmetal. There was then a thin data layer that made the DataContext private, and any code needing to access the database would have to use a public method in this thin data layer. These methods were basically stored procedures; they would perform queries on the database via LINQ to SQL.
Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what? It almost seemed like a hack at the time.
Basically, I'd like to know if LINQ to SQL and sqlmetal is what to expect if I'm go to write a DAL today at a .NET 3.5 shop that doesn't employ a third-party, open-source ORM.
It is still considered best practice to have some sort of data access layer. Whether this is best achieved with a ORM is a heavily debated issue. There is one faction that generally argues that ORM's are the way to go. Another faction argues that stored procedures and database centric is the best route.
Also, this may not be exactly the poster you meant, but it similar (and also the one in my cubicle)
http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf
Your approach is good. I currently use Astroria services (ADO.NET Data Services). There was a nice introduction in MSDN Magazine about this.
I also like the new PLINQO (requires CodeSmith Tools though). This is very slick in my opinion.
When I have such a DAL (service layer), I just consume this service from my client application (Silverlight or ASP.NET MVC).
I think it depends on your use but I'd say with such a thin data layer as you explained that would be your DAL. Most projects will build another layer on top of that mainly for edit/create logic and maybe some stitching logic for gets.
For most of my projects I design it like this.
Repository holds the instance of DataContext and exposes some basic add/delete methods
ProductRepository : Repository exposes general queries (IQueryable)
StoreService uses an instance of different repositories like ProductRepository, SalesRepository and handles all logic for creating something like a product.
So something like...
StoreService.CreateProduct(/* properites */)
This would return some sort of result class.
The best data layer is the one that is plain and simple and gets the job done without any bells any whistles. I have used the technologies you mentioned and written about them here:
The Only Pattern for Data Access is - There Are No Patterns for Data Access
This very site uses LINQ to SQL, so take that as you will.
Officially, Microsoft is supporting Entity Framework over LINQ to SQL in terms of new development. However, there's a vocal group of people who think EF is the wrong way to go. LINQ to SQL will still be around for some time, and is a very decent ORM, if somewhat limiting in terms of which DB backend you can use.
I would recommend LINQ as a great starting point for your ORM. If you need better, look into EF and/or NHibernate.
"Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what?"
The people I know using the 3.5 Framework (and that's just about everyone) - the vast majority - are still using NHibernate. Version 2.0 is a very nice OR/M. I started using it on a recent project and it cut my data access code down significantly, to the point where I really don't want to use anything else in the future. And the Fluent NHibernate API is making some headway for folks who don't like the XML mapping.
I've been programming in C# 2.0 WinForms for a while now. I'm starting to get into ASP.NET and the new MVC framework and the new features of C# 3.5. I've only read a little on LINQ to SQL but have made a few test apps to try it out. In my WinForms apps, I usually had some sort of data access layer, and wrote all the SQL myself. Of course, if something can do that CRUD for me, I'm all for it.
I followed the tutorials on the www.asp.net/mvc website and did both the Entity Framework example and the LINQ to SQL example. So far, they both seem pretty similar. LINQ feels more like SQL, but the Entity Framework feels more like C#.
My questions are:
Is one method better than the other?
What are the benefits of one over the other?
Is it possible to see the SQL that is generate when using either of the methods?
Since I'm new to the ASP world, are web developers leaning on one side?
2: LINQ-to-SQL has the benefits of being simple (but still well engineered) - but the downside of being simple ;-p
LINQ-to-SQL only works on SQL Server (Entity Framework is pluggable; 3rd party variants of LINQ-to-SQL like DBLinq cover some other providers)
Entity Framework supports more abstraction between the data (storage) model and the object model - LINQ-to-SQL is literal table/column => class/property[|field]
LINQ-to-SQL is actually more "complete" in the stuff it does do:
EF doesn't support UDFs
EF doesn't support things like sub-expression invoke (for custom expression trees)
EF doesn't support some "obvious" methods like Single()
EF doesn't have some of the TSQL optimisations that LINQ-to-SQL uses
Basically EF at the moment is a bit more of a "v1" (or even "v0.9") product. However (and importantly) - EF is likely to have a proper next version in .NET 4.0 etc, where-as LINQ-to-SQL is going to see a lot less change. It is still being maintained, but famously Microsoft have chosen Entity Framework as the flagship product (rather than co-evolve both products essentially into each-other). You should think about the long term plans.
At the moment, I'm very happy to use LINQ-to-SQL, but EF is on the long term... so I'm using repository etc to hide some of the gory implementation details - a bit of a leaky repository, but pragmatic.
3: With LINQ-to-SQL, assign a TextReader to dataContext.Log; Console.Out works well - or I have one that writes to the trace.asax. With EF, ToTraceString.
4: I suspect it breaks down a lot by complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines into the object model tend to be using LINQ-to-SQL at the moment (from what I see). People with more complexity and other databases tend to use NHibernate ;-p And then some EF. I'm wondering how much this will change when EF is next released in .NET 4.0...
Use the one that feels best for you, your team and your project. It doesn't really matter how you access the data, as long as you access it.
You could use plain old ADO.NET if you want.