I have 2 projects currently. A dashboard(MVC) and a API. both of them look at the same database but have their own models generated in their respective projects so if you make a change to one it doesn't reflect in the other one.
I want to add a third project for the data and have both my other projects look at that project for any data queries.
What would be the simplest way of doing this and how would the context of EF be affected with the queries sitting in a separate project from where the data is used.
Create a separate project for your Data Access Layer (EF en entities). Then create a reference to this separate project to use it.
Do not forget to add the connection string and entity framework setting to your .config file.
When do not work with code first and in your project you work with multiple Data layers, it may be required you add some metadata to the connection string.
I hope this helps u.
Related
I have 2 web applications which are let's say Legacy1 and New1. I have separate DbContext for both applications and separate databases.
Now I want to migrate data from the Legacy1 database to the New1 database. I cannot simply use copy database or export database options in SQL Server. Entities are different and I need to incorporate some logic while migrating data.
I have decided to use .Net Core Console (.Net Framework) project to do this. Do I have to add both DbContexts to this project? Also all the entities which I want to map and do the migration or is there any other way to achieve this.
Finally i found a simple approach to achieve that. I used EF DB First approach to generate edmx files for source and target databases. Which gives me access to corresponding Entities as well.
I Queried source database using source dbcontext and manipulated data as per the requirements and inserted into target database using target dbcontext. I used AutoMapper to map source entities to Target entities.
It was much simpler than i thought earlier. Hope it helps others having similar scenario.
I've read the MVC5 with EF6 DB First tutorial. With this tutorial, it will generate code (controller and view).
I have created 3 projects in VS:
+ AdminWebSite
+ PublicWebSite
+ EntityFramework
And I've question, where should I implement the business logic, and share it will multiple website (Admin & Public)?
The business logic may include:
Logic with database (i.e. Transaction with multi-table)
Logic with SharePoint info
Logic with Email Server
EDIT
Typo, should be 3 projects instead of 3 solution, but it should be similar case, which AdminWebSite and PublicWebSite have add EntityFramework as reference.
EDIT 2
Before the MVC3, I will create a class project which includes all business logic, and also the Repository class. So that every WebSite or WebServices can use the same business logic (but I'm not sure is it the best practice).
But when move to MVC5 with EF6, the repository and unit of work seems gone. And don't want to implement repository for every table, which some tables just for direct CRUD without business logic.
I hope this can clarify the is Too broad.
Have a look in to this:
http://dombrovsky.github.io/EntityHooks/
It looks like a framework that is designed to work with EF6. It should allow you to write custom business logic when a certain event occurs like when a record is inserted, or updated.
You can utilize Projects under a solution.
I usually have the database layer in a separate project (Class library/DLL) and let other projects refer to it. This way you have only one copy of the ORM (Entity Framework) simplifying any changes in the database model. I also create a database project (if SQL server) that holds the actual schema definitions including tables and stored procedures. This is a great way to make changes in the schema and deploying it.
Anytime a significant enough portion of the code can be re-used it is usually a good idea to make it a class library and have client projects refer to it.
One solution include Web project 、BLL project 、 DAL project，web project contains publish and admin
I would not have a project named EntityFramework, I would suggest that you replace this project with a project named Infrastructure. This infrastructure project would contain classes that depends on external sources like EmailSenders and DAL classes like EntityFramework classes and other stuff that you for some reason in the future might want to replace with other external services.
Your business logic should be stored in a Core project. This core project would not reference either the web projects or the infrastructure project (but the web projects would reference both the infrastructure as well as the core project). If you need an EmailSender in the core project you reference an interface like IEmailSender, which is located in core as well.
This is basically the structure I would suggest:
AdminWebSite
PublicWebSite
Infrastructure
EF
Log
Messages
SharePoint
Core
Test (This project contains all your unit and integration tests)
I really suggest that you read up on using Dependency injection. When you understand DI, the separation of core and infrastructure will make sense and you see how these can use each other without any hard references.
If you dont want to use UoW or Repositories, I would suggest that you move EF to core but the infrastructure project is still very much valid for other external services.
I would like to know what is the advisable approach on creating a project with multiple database using entity framework.
My current solution projects looks like this.
SystemName.Data // Points to Database1
SystemName.Core // Points to Database1
SystemName.Database2.Data
SystemName.Database2.Core
SystemName.Database3.Data
SystemName.Database3.Core
SystemName.Business
SystemName.UI
Should I put the all the Data and Core assembly in one project?
Should I also create different business projects for each database?
Thanks in advance!
In EntityFramework 6 (EF6), you can use multiple contexts on the same database. In EF5, a single user model (DbContext) is managed by only one database instance.
So, the multiple DbContexts can be in different projects, and use the same database instance in EF6.
Update
The databases used by the DbContext could be decided by app.config (or web.config). So, I prefer to put my sub-classes of DbContext into different projects according to their purposes. If the database maximum size is considered, like 10GB per database, then put one DbContext to one database might be a good choice. But in EF6, the DbContext could be considered as a plugin. If the application needs an extension to gain more abilities, then an extra DbContext will create necessary database for the extension. Some day the extension is not useful, and it needs to be uninstalled, then some tables in the same database will be dropped.
I used to have one Working edmx model with WCF service.
Then I've added another Entity Model pointing another connection.
I will try to explain in nutshell what is happened in app.config.
there is still being one connectionString with old name
but now it points new entity model
but initial catalog is not even updated to new one and points to old one
I'm sure that something is wrong here. And I also can't find can I change / edit it from properties.
Is it possible to have two Entity Models in one project? If so then what could cause such things in my situation?
I had a similar problem a while back where I had two models in one project which worked fine at first. My problems started when I had to reference the same table in both models, specifically as the generated POCOs were in the same project.
In the end, put the two edmxs in separate projects. Julie Lerman in this tutorial says this is a perfectly fine thing to do.
Yes, you can have many .edmx models in one project; what you have to do is put each Model.tt in different projects and remove them from the project where are the .edmx models. So you have something like this:
- com.DataAccessLayer
- com.Entities.Model1
- com.Entities.Model2
Each model uses different connection string if you want to connect to different data bases.
Here you can find how to separete Model.tt from Model.edmx
http://nullablecode.com/2013/09/splitting-entity-framework-model-classes-separate-projects/
I have two projects in my solution - Api and Models. Models have MainDataContext that works just fine. I referenced my Models project in my Api project so I can access my models.
Problem is it is saying I need to reference Entity Framework in my Api as well with all the connection strings etc.. I don't understand why I need to reference it in my Api if it is using Models project that already has everything set up.
It seems I need to duplicate connection strings, configurations, references, etc.. What is the point of creating separate project for data access (models) then?
Image with project structure
I see 2 options here:
1 - Instead of exposing the Entity Framework context in your Model project, create an intermediate layer of abstraction that allows you to query the context indirectly. There are plenty of examples in the web about this.
2 - Separate the Context from the Entities themselves and have the Entities in a common layer throughtout the solution, while the Context lives specifically in the Data Access layer