I have created a business layer and data layer for a custom task management system. It just has 2 related tables Tasks and TaskNotes. Now, I would like to build an MVC application on top of it using the Individual User Accounts that you can specify for authentication (ASP.NET Identity).
What is the easiest way to get my tables and the identity tables into one database?
The way to do this is to have one DbContext for all your entities.
You should add Task and TaskNote to your ApplicationDbContext which inherited from IdentityDbContext
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public DbSet<Tasks> Tasks { set; get; }
public DbSet<TaskNotes> TaskNotes { set; get; }
}
Related
Currently, I have EF working perfectly fine with asp net core identity. My web app allows users to login in 2 ways: using their local account and using their azure active directory account. However, only the allowed azure directory accounts are allowed to log in. Therefore, I need to create another table to hold those accounts to cross check when they log in.
If you want to create a new table for the Identity project, I suggest you could try to modify the identity EF's dbcontext with the new create model class.
More details, you could refer to below codes:
public class UserRelationship
{
public int UserId { get; set; }
}
Modify the ApplicationDbContext :
public class ApplicationDbContext : IdentityDbContext
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
public DbSet<UserRelationship> UserRelationships { get; set; }
}
Then you could enable the migration and update the database like this article shows.
I have decided to use code first migrations. I did not use them before. I have, in the past just created the models and then added the tables as needed to the database. I use several SQL Views in my project. I create the SQL View and then create a model for it. It works fine, however when I do migrations it treats them like tables and adds them to the database as a table.
I could use the
modelBuilder.Ignore<AspNetUsers>();
for the view, but is there any way to actually create the SQL view from the model? Below is one of my SQLView entities
[NotMapped]
public IDbSet<StockReportView> StockReportView { get; set; }
If not then I will just continue to create the SQL views and create the model and then add it to the OnModelCreating as modelBuilder.Ignore<StockReportView>();
Thanks for all your help.
UPDATE:
I found a question that was closed but had some answers. I Implemented what they said. Which was:
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
namespace SomeProject.Data
{
[Table("SomeView")]
public class SomeView
{
[Key]
public int NameID { get; set; }
public string Name { get; set; }
}
}
This deleted all of the tables it created That were SQL Views, But did not create the SQLViews.
I have two Model classes to be created using Entity Framework: Skill and Activity. The following are the definitions of each:
Skill.cs
public class Skill
{
public int Id { get; set; }
public String Name { get; set; }
}
Activity.cs
public class Activity
{
public int Id { get; set; }
public String Name { get; set; }
public virtual List<Skill> RequiredSkills { get; set; }
}
Ideally, in the database, I'd want the Activity to be linked via foreign key to a association entity (e.g. SkillActivityAssoc) and the Skill not to have to do anything with it. I don't need to track which activities need a certain skill. I just need to track what skills are needed for each activity thus explaining why I don't have a List in the Skill class. I hope that made sense.
My question is: Is this the right way to go about doing this? When I update the RequiredSkills property of Activity via:
activity.RequiredSkills = someInstanceOfRequiredSkillsList;
dbcontext.Entry(activity).State = EntityState.modified;
dbcontext.SaveChanges();
.., it doesn't work. I'm already speculating that it's because I'm not able to update the association entity. Moreover, my current implementation has a virtual List<Activity> property in the Skill class which I want to get rid of. How do I go about changing my model design and how do I update RequiredSkills accordingly?
Thank you in advance!
virtual is for lazy loading and track changes in EF. You can read more about it here: Understanding code first virtual properties. You should also read MSDN documentation about loading entities in EF: https://msdn.microsoft.com/en-us/library/jj574232(v=vs.113).aspx
Since you want to have more than one Skills in each Activity and each Skills can be in more than one Activity as well, you have a many-to-many relantionship. Please read this example: How to create a many-to-many mapping in Entity Framework? and this http://www.entityframeworktutorial.net/code-first/configure-many-to-many-relationship-in-code-first.aspx
I am a new bie to DDD. In our DDD project ,we have a requirement that our DBContext should only expose AggregateRoots.. Assuming that our DbContext is as shown below
public class ClassContext : DbContext
{
public DbSet<Class> Classes{ get; set; }
public DbSet<Students> Students{ get; set; }
}
and Class is the aggregate root . Is the following implementation the right way
public class ClassContext : DbContext
{
public DbSet<Class> Classes{ get; set; }
private DbSet<Students> Students{ get; set; }
}
Any comment is appreciated
It's certainly useful to think about aggregate roots in your application, but don't try to apply DDD concepts to an Entity Framework class model.
An Entity Framework class model is not a domain model. It's a data access layer. Any considerations regarding including or hiding entities and/or navigation properties should be motivated by facilitating smooth data access and nothing more.
It's highly unlikely that you're always going to read/create/update/delete students through classes only. That would make unnecessary clunky code. And who says that students will always be in a class?
But maybe this isn't the best example of an aggregate. A Student doesn't have an identifying relationship with a Class, because next time he'll be in another class. It would be different with the classic Order-OrderLine relationship. I can imagine that in that case you might only expose a DbSet<Order>.
So just expose the DbSet<Students> as public class.
I don't think the private declaration for Students is needed.
Presumably the Class object contains something like
public virtual List<Student> Students { get; set; }
so, given the requirement that you are only exposing aggregate roots,your code to find a student will always need to find a class and pull the student from it.
Im currently looking at migrating from fluent nHibernate to ADO.Net Entity Framework 4.
I have a project containing the domain model (pocos) which I was using for nHibernate mappings. Ive read in blogs that it is possible to use my existing domain model with EF4 but ive seen no examples of it. Ive seen examples of T4 code generation with EF4 but havent come accross an example which shows how to use existing domain model objects with EF4. Im a newby with EF4 and would like to see some samples on how to get this done.
Thanks
Aiyaz
Quick walkthrough :
Create an entity data model (.edmx) in Visual Studio, and clear the "custom tool" property of the edmx file to prevent code generation
Create the entities in your entity data model with the same names as your domain classes. The entity properties should also have the same names and types as in the domain classes
Create a class inherited from ObjectContext to expose the entities (typically in the same project as the .edmx file)
In that class, create a property of type ObjectSet<TEntity> for each of you entities
Sample code :
public class SalesContext : ObjectContext
{
public SalesContext(string connectionString, string defaultContainerName)
: base(connectionString, defaultContainerName)
{
this.Customers = CreateObjectSet<Customer>();
this.Products = CreateObjectSet<Product>();
this.Orders = CreateObjectSet<Order>();
this.OrderDetails = CreateObjectSet<OrderDetail>();
}
public ObjectSet<Customer> Customers { get; private set; }
public ObjectSet<Product> Products { get; private set; }
public ObjectSet<Order> Orders { get; private set; }
public ObjectSet<OrderDetail> OrderDetails { get; private set; }
}
That's about it...
Important notice : if you use the automatic proxy creation for change tracking (ContextOptions.ProxyCreationEnabled, which is true by default), the properties of your domain classes must be virtual. This is necessary because the proxies generated by EF 4.0 will override them to implement change tracking.
If you don't want to use automatic proxy creation, you will need to handle change tracking yourself. See this MSDN page for details