2

I have developed sites with php in the past and I have now deiced to learn ASP.NET MVC since I find my self coding a lot of c# for desktop applications.

The problem that I have is that I'm use to establishing the connection to the SQL server via functions and custom SQL commands. From what I understand your not supposed to do the same with MVC, rather use the Entity Framework (DbContext) to sync the data between the database and the models. Maybe I'm not fully understanding the logic behind this but I feel that its a waste of resources.

The current application I'm working on requires a lot of the same features as the nerd dinner application (I am currently studying the code) with a lot more search capabilities.

Could someone please give me a better understanding of why I should use the Entity Framework?

Thanks

tereško
  • 58,060
  • 25
  • 98
  • 150
Radar5000
  • 213
  • 1
  • 3
  • 11
  • Well, if you want to quickly code slow-performing app then you should use EF. If you want to write performant app with more effort, than you can look at dapper.net or handcoded `SqlCommand`'s. Using MVC does not restrict you to any way of accessing data. – Anri Jul 01 '13 at 06:56

3 Answers3

3

ASP.NET MVC is entirely independent of database access of any kind; you can pick whatever you want to use. A lot of tutorials will use Entity Framework, though, mostly because it's new and it's easy to use.

Entity Framework simplifies your data access somewhat by mapping your SQL tables to standard C# classes. If you use EF Code-First, you can even do it by defining these classes in C#, and let Entity Framework set up your database so that you never need to touch SQL. Then, because your database and the tables in it are mapped as C# classes, you can add, query, update and delete entries in your database all from C# code. The main benefits are:

  • All your logic in one place, in one language. This includes defining your types/tables, querying, insert and update, everything. This makes it easier to write, easier to debug, and easier to keep it all in source control.
  • Your database entities are "plain old CLR objects" (POCOs). That means you can put them in a List<T>, you can give them constructors to do custom initialisation, you can use inheritance to simplify their structure, clarify their relationships and take advantage of polymorphism in your code... you can do anything you can do with a regular C# class, no mapping or conversion needed.
  • You can use C# query syntax, either like this:

    from x in table1
    where x.foo == bar
    select x.thing
    

    or like this:

    db.table1.x.Where(x => x.foo == bar).Select(x => x.thing);
    

    Both give you compile-time type-checking and IntelliSense autocompletion, and both will generate equivalent SQL and only send the query to the database when you do something that needs to get the actual results, like .ToList().

  • Entity Framework's DbContext class acts like a snapshot of the database, applying any changes back the the database when you call .SaveChanges() on it. This makes it easy to use transactional access and the unit-of-work pattern, which basically means that if something goes wrong mid-operation, you can discard the whole set of changes and know that your database hasn't been messed up by a half-completed task.

There are drawbacks, mostly related to the performance penalty of taking snapshots and keeping them in sync, and the overhead of converting your C# into SQL (and sometimes it'll take more than you need into memory and do the operations there, but that can usually be avoided with a well-written query) but in many cases you won't notice the difference unless your database is enormous. For someone who's new to ASP.NET MVC, I would definitely recommend Entity Framework for database access; it'll take the hassle out of it and let you focus on the logic.

anaximander
  • 7,083
  • 3
  • 44
  • 62
  • There's always [MSDN](http://msdn.microsoft.com/en-gb/data/ef.aspx); from there you can follow the [Get Started](http://msdn.microsoft.com/en-gb/data/ee712907) link to a page full of tutorials and walkthroughs. I'd suggest you start with [Which Workflow](http://msdn.microsoft.com/en-gb/data/jj590134) to learn the different approaches, and then for a learning project I'd recommend starting with code-first. For stuff focusing on using EF with ASP.NET MVC, check out [this page on www.asp.net](http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc) and run through the tutorials there. – anaximander Jul 01 '13 at 15:10
1

You understand incorrectly. MVC has no database support whatsoever. You can use any database technology you want, and MVC has nothing to say about it.

Yes, it's true that most samples and demos use Entity Framework, but that's because EF makes it trivial to do database access in seconds, without writing a bunch of boilerplate code. ORM's are there to map relational databases to objects to better match the data model the object model.

You're free to use smoke signals and carrier pigeons if you like. It might take you 10x longer to finish your app though.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
0

Well I think you are about to compare two approaches i.e. ORM(Entity Framework) and Plain sql objects(Sql Commands). You should take a look at these answers. I hope you'll get your question clarified.

Community
  • 1
  • 1
vendettamit
  • 14,315
  • 2
  • 32
  • 54