Hi I've programmed a fair bit of C#, but never with a database. I'd like to use SQL Server with C# with some framework. Microsoft seems to have shipped a number of frameworks through the lifetime of C#. This makes it difficult for me to search/choose.
Which one should I choose? I'm developing a simple 3-tier webapp. I've watched a few Entity Framework .Net 4.0 videos, but I get the feeling that things are too automatic. I need to do some SQL now and then..
And if I should go for the EF4.0, is this really the best reference http://msdn.microsoft.com/en-us/library/bb386876.aspx
Any recommendations?
Go with Entity Framework 4 - it is the current and future best approach to SQL Server database. It is the basis for WCF Data Services, and the idea of a conceptual model will show up in other Microsoft product, for sure (Reporting Services and others, possibly).
And it does give you a lot of hooks to allow you to execute "on the fly" SQL statements, and you can also integrate stored procedures very nicely into Entity Framework.
And for the "run of the mill" everyday tasks, it gives you nice C# objects - based on your database - to work with.
In my opinion, this is your best choice currently - and the one with the most flexibility and options. You can start with a database ("database first") and create your classes from existing tables; or you can start with a model and have EF4 generate your database for you, and EF v4.1 (due out pretty soon) will also offer "code-first" development where you don't even need a visual model but you can describe all your database objects and settings in just C# code.
Update:
Entity Framework 4 Overview
Learn Entity Framework - the site accompanying the book by the same name, by Julie Lerman, Goddess of EF :-)
ADO.NET team blog with lots of good EF stuff
Entity Framework team design blog
ASP.NET 4.0 and the Entity Framework 4 - Part 1 - Create a Database using Model-First Development - good intro for EF4 model-first approach; Vince has multiple articles here - click on his name to get a list of all his articles (many new ones EF4 related)
Introduction to Entity Framework (this was for v1 - but still good)
C#+ActiveRecord+NHibernate. Hide the implementation behind several WCF services.
You said you want to try some 'framework', so Entity Framework is that one. It is the result from best practices MS come up with after years of research. Of course, on the way, you can always use SQL (Dataset) anytime you want together with EF (mostly for performance tuning).
I would say Start with Rob Conery's Sub Sonic..
Its easy to start with..specillaly Simple Repository..
Site Link: http://www.subsonicproject.com/
Simple Repository using Sub Sonic:
http://subsonicproject.com/docs/Simple_Repo_5_Minute_Demo
Update:
I have seen one answer mentioning NHibernate and want to add a small addition to the same... and since OP mentinoned that you have good experience with C# I assume you have good OOPS knowledge and also the relationships amongs objects
I personally felt much easy to start with NHibernate when used it with Fluent NHibernate hence I would also suggest
C# + NHibernate + Fluent Nhibernate....
Take a look here for some information about performance/benchmarks on various ORM frameworks for .Net.
Related
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
What is the current status of linq2sql and is it sensible to use it still?
I am about to start a very large project and have quite a lot of experience with it.
However I don't want to avoid EF if that is really the way to go. I do like the simplicity of linq2sql.
In my opinion: no.
Why?
EF in v4 is just as easy to get started with as Linq-to-SQL
EF 4 also has options to do more complicated and advanced things - if you need to. No luck in Linq-to-SQL, really - it's simplicity is all there is - no advanced features
EF 4 has various approaches to building your system - Linq-to-SQL only has "database-first"
EF 4 allows you to update your model (if you're using the database-first approach) if your underlying database ever changes - is there any change it might?? No such luck with Linq-to-SQL - drop the table and drag it back on; tough luck if you modified table or column names, or added additional e.g. associations...
Linq-to-SQL was really more of a proof of concept to show off the capabilities of LINQ, developed by the C# language team. It was never really meant to be a full-fledged ORM. EF on the other hand was developed by the ADO.NET database team, and was intended to be a real enterprise-grade ORM / conceptual data model. Linq-to-SQL will not see any further development to speak of - maybe a bugfix here or there. EF on the other hand is Microsoft's strategic platform - they'll heavily invest in it and continue development here (see e.g. the "EF Migrations" to automagically update your database schema from within code).
My personal take: if you start new and you're on .NET 4 (or can go with it): go with EF v4. You can't go wrong, you have all the niceties of Linq-to-SQL - and then quite a few more, if you need them some time in the future....
Personally I'd try to make it such that the database layer is an implementation detail, behind a view-model, repository layer, and other such devices. Then the only question is:
does it work?
To which the answer will probably be "yes", but by abstrating that you can change it without much risk / re-work. Perhaps to the "fuller" ORMs (NH, EF, LLBLGen etc) - or perhaps the lighter micro-ORMs (dapper, simple.data, massive etc).
If L2S lets you get started quicky, there's no reason it can't be used. It might not be my first choice now, but it is a good tool, and I find it more intuitive than EF in many areas.
The key, though, is not painting yourself into a technological corner where change is too expensive.
Linq-2-SQL is dead... no matter you hear around
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
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.
The question header is clear, i want to know why its different and why, when to select it for my project?
I wrote a blog post on this a while ago. In short, it takes a fundamentally different approach to ORM than Hibernate, ECO, and the other ORMs that I have looked at. You may think this approach is better, worse, or unimportant, but if you look deep enough it's hard to dispute that it is different. But don't take my word on it. If you're really interested in this subject, I strongly recommend reading this technical paper and this interview in ACM Queue.
This is probably not the answer you are looking for but I dont think you should use it in your project. It is very young and not very complete. Wait until the next version comes out.
If you insist on using Entity Framework there are a few good things about it. A nice one is the way it allows for complex mapping in a very simple way. And of course because it is a microsoft technology the IDE integration is nice.
But like I said, I tried it and I dont beleive it is ready for real use.
Anyway good luck at your project
ADO.NET is not an ORM.
Basically the difference is the level of abstraction used in each one.
With ADO, you basically query the DB and use the results as objects, is like a bridge between the RDBMS and your objects.
You model your DB and then you create object from that model. That's why it is an Entity Framework ( db entities )
ORM are not for querying or represent database records as objects ( although that's how everyones uses them anyway - me included - ) but a way to persist your object model into a relational database.
They are Object to Relational Mapping ( not Relational to Object Mapping )
So, you choose one or the other, when you have a domain ( object ) model and you want something to persist it ( to a RDBMS ) or when you have a entity model and you want to use it as objects in your app.
From what I've read, it has good support for WCF remoting/binary serialization, which is something many ORMs don't support very well (if at all). It might be worth looking into if you want to create a rich client/server/remoting app with ORM on the client side.
What different? It didn't learn from all the other ORMs.
Here are the issues I've been tracking for InfoQ
Does LINQ-to-Entities really return different results depending on previous queries?
Working Around Entity Framework's Large Data Model Issues
No Change Tracking for ADO.NET Entity Framework 2010
And this tool is a must-have if you do decide to use it.
Meta-data Synchronization Tools for LINQ to SQL and ADO.NET Entity Framework
Some of the best talent in the ORM world in .NET seem to be working on projects such as NHibernate (free-open-source; I use it) and LLBLGen Pro (commercial).
NHibernate is the reigning standard for enterprise-quality full-scale multi-vendor ORM. NHibernate is also the reigning standard for a pure implementation of ORM, permitting you the developer to write domain models completely independently from the NHibernate infrastructure, and completely eliminating code-generated classes.
NHibernate may look scary at first. But it is actually fairly friendly once you work with it a bit, and work has been underway since July to make NHibernate nearly configuration-free.