I'm trying to set up Entity Framework 6 in my project to facilitate the programming. However, I'm facing some kind of weird trouble.
I tried to follow this tutorial but with my own DB. http://www.aspsnippets.com/Articles/Simple-Entity-Framework-Tutorial-in-ASPNet-Web-Forms-with-example.aspx
As I tried to create an ADO Entity Data Model, everything worked fine and I got my model done. I'm able to see it in the model explorer. However, I'm not getting anything in my "Models" folder, and I cannot add a reference to my model in my using statements.
Which makes me not able to create the kind of functions as described in the tutorial.
Has anyone a clue about how to solve this?
Using EF with Database First or EDMX First will hold you back while learning Entity Framework. The best way to learn it is from the ground up, using Code First. DB or EDMX First only really come into play when you're reverse engineering old databases, and even in these cases, you'd be better to rewrite the database in Code First and phase out the old one.
There is a really good tutorial I've found here: Entity Framework Code First End to End. It teaches best practices, as well as going into detail about how and why it all works. It's one of the best ways you can spend 75 minutes when learning Entity Framework.
Start off small, and build outwards. In EF7, they are phasing out the EDMX, so even when working with Database First, you'll need to know everything about Code First in order to make it all work properly. The scaffolded code generated by Database First is really badly written, and needs refactoring as soon as it lands. You'll be refactoring and adapting the code anyway, so Code First is,in most cases, more straightforward.
Related
Well I have been programming odd applications in C# for awhile. I am fairly adaptable to any language. That being said I am by no means an expert. I can get done what I need to and it is fairly clean. The one area that perplexes me is working with database. I understand how databases work and even write some SQL queries. The biggest trouble I have is I use visual studio to auto generate code and it was mentioned in a previous question to stop using that. Well the time has come that I believe it will be beneficial for me to learn the basics of connection to a database and creating the auto generated code that visual studio usually handles. Can anyone here provide me with a place to best learn this? I want something that will guide me on best practices for performance and clean up not just how to make it work.
Thanks in advance
If you want auto-generated code, are you wanting Entity Framework Code First? I noticed you didn't specify.
This is the official documentation for Entity Framework.
https://msdn.microsoft.com/en-us/data/ee712907
I'd focus on the Code-first portions and probably don't even worry about the EF Designer, Model First, or Database First in there.
Some key concepts you want to make sure you understand.
Code First
Fluent API
Scaffolding
Data Annotations
Migrations
I've been practicing the Code First concept on my database. Since I have worked with databases longer than .NET Code Development, I tend to always consider ways to leverage the power of the database and so my standard practice has always been Database first and then use an ORM like EF to generate the context for the DAL.
So please excuse if this may seem like a stupid question. I've been getting accustomed to using the Code Migration utility to create my primary and foreign key relationships, define Primary Keys and etc. Great learning experience but for some tasks I think it is better to simply go straight to the database and run a script. Such as creating check constraints, stored procedures to implement as functions in code and etc.
So my question is, if I perform a task like creating a check constraint in the database is there any way to propagate the change to the code first model? I know the update-migration command will force changes in the model to the database so as I am a beginner to this method I am wondering how can I get Code First to receive changes in the database as opposed to pushing changes out.
I ask because everything I've learned so far seem to enforce the term "Code First" as if when you begin developing in this mode, you cannot reverse the logic if needed.
Is this right or am I simply missing something???
Also, is it considered a common or reasonable practice to use Code First and EF? Seems as though Code First provides the same benefits as EF and so it would seem to be a redundant use of code.
i've created a database in sql server. After that, i choose to use Entity Framework for the first time of my life. Reading a few posts here, i used the Reverse Engine Code First and it created all my models from my database. Works great, but always when i'm trying to understand a problem, peoples says about the edmx, which i dont have. Why?
What is the real best way to design a database first and use the EF after?
For example, i dont know how to update my models after changing the base. I always need to run the Reverse Engine Code First Tool again, wich messed with a lot of other things.
I'm really loose, and sorry for this post if has another one equals. I tried to search but dont know the right terms to search. Its my first time with EF5.
Thanks
EDMX files are used when you have Database First and want to use as ADO Dataset.
I'm just starting out an extremely large web project, and really trying to do everything right.
My tools using so far are
ASP.NET MVC 3
Entity Framework 4.3
Ninject 3
All is going well, but I'm finding a few things with Entity Framework CodeFirst a bit sketchy.
For example, I had to use http://codefirstmembership.codeplex.com/ to setup membership information as part of the code first setup. This feels a bit ropey to have to use something third party of this. Obviously I should be 1337 enough to "roll my own" but I don't want to bite off too much from the get go. Running aspnet_regsql feels horrible, and will get lost with each db update. Anyway, got it all working with the above library and it's not too bad. Scaffolding seems to have broken however.
Now beyond all this, it now seems that this stuff is going to become probamatic when I am running in the live environment. Any schema changes I'm going to want to make between the dev db and live db will have to be manually managed with scripts anyway, so at that point am I not losing the point of code first?
I've been working with Google App Engine for the last year, and was hoping that code first would essentially work in the same way? Ie, make changes and they modify the live data. Now I assume, due to not having done severe refactoring in app engine, that it basically doesn't harm anything in production. So you could never rename a table with AppEngine. It would always create a new table, and leave the old one. You would have to manually port data.
So I'm now thinking. Why not just go Database first? I've been working with linq2sql for 3 years and very comfortable with going db first. Although TBH my db source control stratergy has been a little....lacking. So I was hoping code first would enforce that situation to improve, but it actually makes me feel that I should go DB first, and just be strict about keeping it under control.
I would really appreciate any thoughts on this kind of situation, and also, how does this compare to using Nhibinate?
The upgrade scenario's you're describing are being added in EF-Migrations. The go-live release of this is already available and it should become available as a officially supported release version soon.
Check out: https://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx?Redirected=true
Check out: http://coding.abel.nu/tag/ef-migrations/
Just my take on this...
You don't need to make a choice for good -
you can use Seed, custom initializer (and migrations hand in hand - with migrations you can actually manually change them, e.g. add indexes there etc. - though carefully), to 'inject' the raw SQL (and most of the needs could be covered by that). As far as I know you could run a custom batch file form initializer (but haven't tried, though I don't see why not). Migrations are done through PS so I'm guessing there is space to integrate on that side too.
You can use it to prototype things and startup - get your C# structure in place and in sync fast - then shape it up later - or once fixed use some 'use existing initializer' which does nothing from the code and move everything to Db side and your DBA.
IMO, you can go 'very far' in this sense, before actually needing to turn CF off and just work from Db.
For larger databases, or corporate environments, it's definitely not the right tool for the job.
I think it's now safe for production - but depends on what you consider safe, few things...
Also, EF/CF has gone a long way since the beginnings really - I used it since the start - and it had big problems initially. The latest versions are now pretty solid on all sides, so it's getting there I think.
...on the downside - I had worked out some pretty complex scenarios with code first approach (EF and otherwise). However, few things held me back with EF (on top of what you mentioned)...
UDF support, views (with linq - as if you're not to use LINQ one of the big 'pros' is gone) - which should come up in EF 5.0 (I did not check but it's what they're promissing) - as for more complex scenarios you need to optimize on the SQL side (or to be able to execute custom queries on the back and then map back, i.e. more flexibility on that side). So that's a promising thing if it comes (though won't be perfect I expect). (on the plus side, you can actually run custom queries and then map to your objects - but that sort of works, and you cannot do everything so it's limited in a way)
Performance with queries and again for more demanding heavy duty scenarios - that was my main problem with it. That's also promised to come up better in EF 5.0 - so to wait and see.
Having said that -
my favorite is a custom or open source code first like solution, ORM - where you can have more things under control. Still having many providers support etc. is what makes 'official' or MS implementations more viable on a long run.
hope this helps any
This questions actually refers to another one already asked, now I want to reformulate it :)
My issue is: There is an online shop running on MySQL database, hosted somewehre on the internet. Now I'd like to do some administration stuff from my C# application.
What I want to do: All I want is to run SQL-queries on that database and get the results as entities in my application so I can browse through them like through normal Lists/Classes and then post back the changes to the database. The problem is not the connection to the database - it works fine (using SSH and Connector/NET driver) - but the question, how to turn the SQL-results into C# classes.
I had a closer look at Fluent NHibernate and SubSonic, but I still can't figure out which one suits best or - even worse - if these are really the right approaches to my problem.
So I don't want to build an application which stores its own data in a database but gets the data it needs from a public database.
I hope I could make myself more clear this time :)
Thanks in advance!
ORM is definitely the way to, because it allows you to abstract your data access.
You may find a code generator helpful (to avoid the repetitive task of writing the classes and all their properties): NHibernate Code Generation.
This way you can still use classic NHibernae instead of Fluent Hibernate, which by the way looks pretty useful.