I am having trouble getting started on my first attempt with EF and Code First mostly due to trying to find an efficent way to organize the project in Visual Studio. I wanted to try Code First so I pictured a set of class files in a separate project to describe the entites, like MyApp.Models. To build on that I imagine I need something like Fluent API to make sure the database is created the way I expect which is where I hit the first snag. I think the only way to do this is to define the context where EF generates the database. So where should that code creating the context be defined? In a separate project like MyApp.DAL? I'd also like to include Asp.Net Identity 2.0 which I believe is part of defining the context so that is included in that step. Next I assume I need to actually call the code so EF can generate the DB which requires at least a configuration setting for the connection string. Eventually I want an MVC app but maybe next is a console EXE like MyApp.ConsoleTest? Also I'd also like a Web API project which would serve the MVC app. I think those can be covered with something like MyApp.WebAPI and MyApp.ClientWebMVC. Perhaps later I could also create MyApp.ClientWPF which would leverage the work done with the Web API. Along the way I should also probably have something like MyApp.Common or Shared.Common to hold things like logging and error catching.
I think the first few steps around the entities and context are what trip me up the most. I want to try and organize the data part of the code so changes can be isolated from ruining too much in the client apps. Is there a good tutorial on project organization that addresses EF Code First that isn't overly complicated (ie Unity of Work)?
Related
At work, I use ASP.NET MVC (not .NET Core) with Entity Framework and SQL Server. However, I wanted to practice a bit with ASP.NET Core MVC and some other SQL Server stuff (like experimenting with SSIS) at home, so I set up a small dev environment for me to work in. I created my database and tables, populated it with information, and created the default template you get with ASP.NET Core MVC. No issues so far!
But then, when I went to add a model into my project, I had no option to add an ADO.NET Entity Data Model like I do at work. After googling around a bit, I saw a mention that you could not create these kinds of models in .NET Core applications: https://learn.microsoft.com/en-us/answers/questions/357012/can39t-find-adonet-entity-data-model-missing-visua.html. I did some more googling, and it seems like just about every single thing I'm finding online is that you have to use package manager console, and type it all out.
Is this really the only way? Surely there has to be something better... It was very nice in ASP.NET MVC when I could add the model, and then it would take me through a wizard to get everything set up. I could create a new connection string, test the connection to the database, select which tables/views I wanted to add to the model, and I was all set! It was just as nice being able to go into my model and easily update the model with new tables, columns, or anything else I needed.
I get that code-first solutions are more mainstream these days, but I want to stick with the database first approach. Is there a simple, user-friendly (non package-manager console) approach for me to add models like I used to, but still get the benefits of .NET Core? Any good tutorials out there to get me on the right track (that aren't code first)? I appreciate anyone who can point me in the right direction!
I am sorry if I am asking something that has an obvious answer, but I have spent and entire day searching for resources on the subject and I fail to find or understand how to do a few basic thing with EF7.
So, here is my question.
I have an ASP MVC 5 (VNEXT) website and I am using Entity Framework 7. I have an existing database, thus I am working database-first.
So far everything was fine. I installed everything required to get my DNX EF commands up and working; I scaffolded a dbContext and I got all my tables as classes and a dbContext class.
Everything fine, all well. I was happy and continuing with my work.
However, I got to a point where I wanted to make a property of one of the generated (table) classes Required, because I use jQuery unobtrusive validation.
I have the following resource as a reference: http://ef.readthedocs.org/en/latest/modeling/required-optional.html
My first wonder is, according to this source, in the FluentAPI the property has been marked as .IsRequired(). I believe, making it required here is a whole other thing that has nothing to do with unobtrusive validation. So, the next thing explained is simply - go to your class and add the Required data annotation.
This is all fine and well, and after adding it, it works as it should.
But I immediately wondered - well, I am modifying the generated classes, am I not going to lose those changes once I update the model?
Which leads me to my final problem - I searched for a long time, I even played with the help menu of DNX EF, but I am unable to find the right way to update the dbContext and generated models after I make changes to the database.
I believed this to be something quite trivial but to my surprise I am unable to find a resource explaining how to do the update.
Can you point me in the right direction, and tell me how to update EF generated models and context after I make changes in the database schema, and what is the best way to add annotations to the properties of the generated classes?
The general consensus is that you shouldn't use your database entities as input from users directly. Instead, use ViewModels, verify those against your validation rules, then map them to database transactions.
As asp.net MVC developer I use database first and updating database is a big head ache so I use Metadata approach and create ViewModels which helps allot.
I want to develop an ASP.Net MVC application with EF4 Model First design and only generate the actual database much later, ideally at the end of the project.
Based on some of the ideas here:
http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/
I want to create something like an InMemoryObjectContext for testing and development and use IOC to switch to the SQL Server implamentation (EF generated) for UAT and production.
Is this wise?
Is it possible? If so, does anyone have any suggestions?
Does EF always need an underlying database in order to track changes, commit etc?
I've tried creating a model first but as soon as I add properties I get the following errors:
Error 2062: No mapping specified for instances of the EntitySet and AssociationSet in the EntityContainer Model1Container.
and the warning:
Running transformation: Please overwrite the replacement token '$edmxInputFile$' with the actual name of the .edmx file you would like to generate from.
The error doesn't stop the application running but worries me. I'm very very new to EF so I apologize if this is way off the mark or a dumb question. I'm hoping to get some good advice while I sit for the next few days and watch videos and read articles.
Thanks
Davy
At the very least you need mapping information "filled in". You can fill these fields with nonsense if you don't want to work against the underlying database.
If your doing Model first, right click on the designer canvas and select, "Generate Database from Model". This will automatically create convention based mappings for you without defining tables and columns. You don't even need a valid db connection to do this.
we are building a new web application using Microsoft ASP.NET MVC2 and Entity Framework 4. Although I am sure there is not one right answer to my question, we are struggling to agree a VS2010 solution structure.
The application will use SQL Server 2008 with a possible future Azure cloud version. We are using EF4 with T4 POCOs (model-first) and accessing a number of third-party web-services. We will also be connecting to a number of external messaging systems. UI is based on standard ASP.NET (MVC) with jQuery. In future we may deliver a Silverlight/WPF version - as well as mobile.
So put simply, we start with a VS2010 blank solution - then what? I have suggested 4 folders Data (the EF edmx file etc), Domain (entities, repositories), Services (web-services access), Presentation (web ui etc). However under Presentation, creating the ASP.NET MVC2 project obviously creates it's own Models folder etc and it just doesn't seem to fit too well in this proposed structure. I'm also missing a business layer (or does this sit in the domain?).
Again I am sure there is no one right way to do it, but I'd really appreciate your views on this.
Thanks
Jfar is correct. It doesn't matter at this point what structure your solution takes. You'll have plenty of time to rearrange the solution later. I've done many small MVC applications and one large one and I'm still evolving how I prefer to structure the projects/solutions.
As far as structuring and MVC project, the only folder that really matters is Views. I have started to break away from the /Controllers and /ViewModels folder structure and grouping things by domain concept. If Student is one of your domain concepts, I'd have a Students folder in the domain project, in the MVC Views folder, in the services project, etc. All the domain classes, view models, controllers, etc would go under the same folder name (in different projects). That way you always know directly where to go to if you want to modify Student related code.
Also, we have a Web project that hosts the views and a separate class library project that contains the controllers. Most of my solutions have 12-30 projects.
I believe you are right to consider the project structure (and namespaces) at this early stage. Although jfar's point is well made how often are you given the luxury to restructure your projects and namespaces before your first release? Even something as you suggest is better than throwing everything into the same project - surely?
Wanted to add - it's not so important how You organize Your folders/solution, it is important how You organize Your code.
So - If Your app won't be properly layered using fancy techniques like dependency inversion, won't be neat and testable - it won't matter if You put stinky code in one or hundred folders. You won't be able to migrate from sql to Azure, from mvc to silverlight.
What makes sense to you and your team?
What folder the code is in means nothing ( besides minor namespace generation ) and can be easily changed by dragging and dropping.
Right now organization barely matters, you have so little files its easy to browse around the slution. Once your 6 months in and you have 1000s of files thats when you'll need to start thinking about organisation.
With my own personal projects I dump everything into a single project, at work I have a 17 project solution and 50 folders. Code is code.
When you start creating an application or site in ASP.NET MVC, what do you do before typing in that first line of code?
I'm personally fond of creating a new ASP.NET MVC Web Application project and then cleaning out controllers/views until I have what is essentially a blank project (i.e. it runs but doesn't offer functionality). Then I start working on my model and adding controllers/views as needed.
I've also read about starter kits and sample applications but I have not yet started actively working with any of them. However, in my reading I have seen authors suggest that it might be good to start off with an existing template and build on it.
I'm trying to determine if there are better ways of starting off a project such that time is saved and/or the resulting deliverable is of higher quality.
The other things I do (I also clear out the controller/views etc)
Put an IOC in place.
Put ELMAH into the project.
Then I grab a coffee and write my first test.
Kindness,
Dan
PS: At some point I shall get around to creating a template for this so I don't redo it everytime. As soon as I decide upon my favourite IOC. :-)
I usually clear out the Content folder as well and put in place a nice CSS reset file and/or a CSS framework like the 960 grid
Before starting any type of project you must know what you want to do. So take a sheet of paper and start writing on here:
The name of your application
Enumerate the features
Make a quick draft of the domain model (entities that you are going to have)
Try finding the ways (choosing a technology) you are going to do different stuff like: data access, validation (client and server side), logging, IoC, Security, Caching etc.
Do a quick draft of all the views you are going to have in your application
Identify any other problems you might need to solve/implement/develop and think how are you going to do that