I am building an asp.net mvc application that is using Entity Framework 6. We have the challenge of building several implementations of this same application. So we have created a core library called MyApp.Core which contains the following:
DbContext
Models
Customer
Product
(other models)
Repositories
We have the need to extend models for different implementations of the application. For example we might want to put SomeProperty on the customer table for 1 customer and SomeOtherProperty for another customer.
How can we improve the structure so it doesn't break the EF code first migrations? Or cause any other issues?
Should we just have a unique ASP.net project for each customer that references the MyApp.Core? And should we reference those via a nuget package? Or something else like a git sub module?
Any suggestions on the organization of the custom implementations of this type of structure?
Your solution may be an IsA (Is-a, is a) database structure that can be created from your code-first model using the TPC method mentioned here:
http://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines
You might create an abstraction such as ICustomer, or CustomerBase which contains a reference to a table containing the implementations of your application (is that Product?).
You might also transform your Customer class into a base class, and other classes with additional fields would inherit from it.
In either event, the article deals with bringing code first into a database model that can handle this kind of thing. You may also want to take a look at multi-tenant architecture, just to say you've done your homework. That's here: https://msdn.microsoft.com/en-us/library/aa479086.aspx
Related
My solution is based on Clean Architecture.
The Domain project should be completely ignorant about the Infrasctrure layer.
The Infrastructure contains a Data Project and an Identity Project.
The Data Project is supposed to implement my repositories. It contains a class called ApplicationDbContext that inherits from DbContext;
The Identity Project is supposed to implement the AspNet Core Identity and all its needs. It contains a class called PortalUser that inherits from IdentityUser and also contains a class called ApplicationIdentityDbContext that inherits from IdentityDbContext;
In the Domain, I have an Entity called User.
User is referenced by several other Entities, like Company (A company has several users).
I'd like to have only one table for both my entities User and the PortalUser.
When I try to apply the migrations, I have several problems referencing User.
What I tried so far:
Create an owned Property called User in PortalUser. But I can't map User in Company entity to an Owned Entity;
Map both User and Portal User to the same table called User, using different DbContexts. But when I apply the migrations to the Database, the migration fails and says that "A table User already exists";
Implement all properties from User in the PortalUser. But when adding a migration it fails and says that other entities like Company can't refer to User.
Make ApplicationDbUser inherit from ApplicationIdentityDbUser but two problems: 1st, it's conceptually wrong to the Clean Architecture; 2nd, The same issues related to having only the PortalUser being created and all other entities referencing User.
I'm stuck on this problem and the project is not going far. All examples that I found so far are raw and don't show what happens when I have navigation properties referencing the User.
The better solution I could think of so far is to have two different tables, one for Identity and another for user needs and references. However, I'm migrating this solution from a messy solution to a more well-organized one, using Clean Architecture. The old version uses only one table for both situations and I can't have a new table and migrate the data.
PLEASE, anyone knows how to solve this problem?
I am building a new ASP.NET Core 5 MVC app. I want to use clean architecture as outlined in Microsoft's web app architecture ebook.
I am also studying eShopOnWeb sample application available here :
https://github.com/dotnet-architecture/eShopOnWeb
What I understand from the ebook and sample app is - EF Core entity classes (say Customer, Product, Order) will go inside ApplicationCore project's Entities folder. The DbContext will be in Infrastructure project.
My confusion is: is it alright to add data annotation schema attributes such as [Table], [DatabaseGenerated], and [Key] on these entity classes inside ApplicationCore project? If not, where should I add these data annotations?
Any advice in this regards is highly appreciated.
Thank you.
In the example of eShopOnWeb they separate Entities and configuration models. So, that means to have clean architecture you don't need annotations directly in these Entities.
You can use FluentAPI, as they used as well in the Infrastructure/Data/Config directory.
So, if you have a separate project for DataContext that is the best location for describing your entities with FluentAPI in this case.
More information about FluentAPI:
https://learn.microsoft.com/en-us/ef/ef6/modeling/code-first/fluent/types-and-properties
I am analyzing a system in c# that has 2 libraries: Business Layer and Data layer Access.
Business library has:
1 BaseManager.cs class
Several Managers (ClientManager.cs, ContactManager.cs, etc).
1 BaseEntity.cs class
Several Entities(Client.cs, Contact.cs, etc)
1 NotifyPropertyChange.cs class
The data access layer has:
1 BaseData.cs class
Several data objects (ClientDatasql.cs, ContactDataSql, etc)
Several interfaces (IClientData.cs,IContactData.cs, etc)
1 Class called DataFactory.cs
All the classes in the library are partial e.g.
Client.cs, Client.Generated.cs
ContactManager.cs, ContactManagerGenerated.cs
BaseData.cs, Basedata.Generated.cs
Etc.
All this classes were generated with a code generator, this code generator was written by someone in my workplace.The approach used was "Data Base First", Entity Framework was not used to do that.
My questions is:
How can I start to create my own code generator in order to generate that kind of classes?
Is there any tool to help me to do it?
Or should I write it from scratch?
What kind of topics should I start to read?
Thanks in advance.
It's probably a good idea if you start by reviewing exactly what Entity Framework is, and what it provides.
My favorite starting point when I have an EF question is often msdn.microsoft.com/ef.
In your specific case, EF supports a workflow called Database First where an existing database is used for the basis of the entities that will be used. There are a number of tools available that can take a database and generate entity classes from it. Here is a basic example of how that's done.
I am new to Code First. I am interested in using Code First going forward on my projects. I am using EF 6.xx. I will be creating several projects using an existing database but will be adding additional tables/views/stored procedures where necessary. Perhaps a silly question... Can I develop a library of POCOs that are tagged with the appropriate Fluent API tags and then pick and choose what Fluent API tagged POCO library classes I want to include in the OnModelCreating method for the particular project. I'm interested in re-using the same POCOs from project to project. Is this what others are doing or are they re-creating the POCOs in every project?
Thanks in advance,
Terry
You can certainly re-use the POCO classes between applications. If they are not referenced directly by your DbSet subclass or indirectly by another class that is already referenced then they won't be used by EF.
You can use attributes (what I think you mean by tags) on the various POCO classes as long as those attributes are the same between all projects that will use them - e.g. column name etc.
For stuff that changes between projects you'll definitely want to use Code First's fluent interface to configure them in the OnModelCreating.
I am doing some prototyping and have a small database (4 related tables) which I developed an Entity Framework 6 project around (DLL with models for the tables). I've added an ASP.NET MVC 4 Web App to the solution that includes Repository interfaces/implementations under the model folder. The Repositories add interfaces for CRUD operations against the EF project. The Web App has a set of controllers providing REST interface through the repositories. Standard stuff I believe.
The issue that I have is I want to create an aggregate class the wrappers types (models) defined in the EF and return that aggregate in response to a Get request. The question is where do I define this aggregate object? The EF project? (and how?). An independent class library (usable by a client)? The Web App?
Trying to keep all the model definitions in the same place that understood by a client and Web App service at the same time.
Thanks
I believe what you want here is the DTO (Data Transfer Object) pattern. See here and here for basic explanation of the pattern. The idea is that you define a set of classes distinct from your data access objects (EF classes in your case), whose purpose is to relay data between your REST interface and its clients. If you have C# clients to whom you want to make the class definitions visible for simplicity then I would suggest putting the DTO class definitions in their own class library project and have the server and client both reference that dll.