Develop Reference

Entity Framework Core and REST client - code organization

I'm building a solution with three projects:
.Data (holds Entity Framework Core-classes and Writer.cs)
.ConsoleApp (Startup project, calls Writer.cs)
.CloudTalker (Web Services references and Fetcher.cs)
The purpose of the solution is to call REST APIs, get entities from the APIs and store them in a database using Entity Framework Core. All code is running fine but I am positive there are ways to improve the architecture.
Example code flow to fetch Customers from the REST API and write to the database:
Program.cs in .ConsoleApp instantiates Writer.cs and calls method WriteCustomers().
WriteCustomers get the latest modified date for Customers in the database
WriteCustomers calls GetCustomers( latestModifiedDate ) in Fetcher.cs in the CloudTalker project. This method returns and array of Customers (the class returned by the REST API, not Entity Framework).
WriteCustomers loops through the array, converts the REST-object to an EF Core-object and puts it in _context.Customers.
Context.SaveChanges() stores the Customers in the database.
Now to my questions/calls for opinions:
Have I done a decent separation of concerns? What is bugging me is that either the CloudTalker needs to know about the EF classes or the EF classes needs to know about the REST classes. Which way is preferred? Should CloudTalker.Fetcher.GetCustomers( lastModifiedDate ) return objects from the EF Classes or the REST type?
How should I handle naming of the classes? Right now I have two Customer - the REST kind and the EF kind. Not pretty.
Anything else I should do differently?
Thanks in advance for sharing any insights.

Seems to me that this should belong to codereview website but here's what I think about the architecture (I am disregarding the fact that this could be a simple project that can live with a quick and dirty solution)
The writer should be in a separate project and should only know about EF and DB, The fetcher should only know about REST and how to call remote services. You can then introduce a service layer that knows about the two former bricks and calls the fetcher to get the data, then pass the data to writer.
I assume there's no business logic so no need for a separate domain project. Your service layer can be directly in your UI/Console project.
For the naming, how about CustomerReadModel, CustomerWriteModel?
It seems that you also need to read from DB to get the last modification date, so I would suggest having a reader somewhere in your db project.

Should I include Entity Framework in my class library or directly into application?

You might have encountered this type of question before but in my case, it's a bit different scenario and I cannot find a feasible answer. (It might exist already, however I was not able to find one).
I'm working on a business application which has the entire functionality split into multiple class libraries. I'm using Entity Framework and I'm not sure which is the right place to include it? In my case, I've these libraries:
Project.Library.Core
Project.Library.Models (Contains the entity data model and entities).
Project.Library.Auth (Contains authentication related and user management classes).
and similar classes who frequently use the entities and the db context.
In order to make this work, I've to install Entity Framework in every library separately. Eventually they will be included in a number of ASP.NET MVC Web Applications. I'd have installed Entity Framework directly into the web apps but this application will have mobile apps in the future along with a possible windows store app. In that case, I can simply set up a ASP.NET Web API and use the existing class libraries to generate the required data. This is the only factor holding me back from incorporating Entity Framework directly into the web apps.
So what's your opinion on this? Include Entity Framework in every library separately (required to function properly) or simply include in the web app and later follow the same approach for the Web API?
Thank you.

You only need to "install" EntityFramework into one place: Project.Library.Models. Assuming standard code-first objects as your DTOs, you won't need a direct reference anywhere else as long as you wrap the context object with a Data Access Layer.
Adding a reference to that assembly will cause the requisite DLLs to be included with your apps, web sites, etc. Note that if you are using EntityFramework.SqlServer, the transient dependency won't be detected by Visual Studio so you need to do something like:
class Include
{
private Include() { }
private SqlProviderServices IncludeSql;
}
Somewhere in the models project so that DLL is copied over also.

ASP.NET Identity DBContext or Site DB Context?

I've been kind of out of the .net game for a while and I wanted to try the different new technologies.
I set up a site that uses code first migrations with EF 6 and MVC. The DBContext is created in my DAL and I'm using a repository / unit of work / n-tier implementation. I've created a User entity that holds profile information and a DBContext, let's call it SiteDbContext.
Now I'm at the MVC part and I'm trying to figure out the ASP.NET Identity. I have a few questions:
1) Should I use the ApplicationDBContext created in the UI along with SiteDbContext or dispose the ApplicationDBContext and use SiteDbContext (and just make sure it inherits IdentityDbContext)?
2) If I use the same DBContext, will it be a problem if I create a dependency on the asp.net identity in my DAL layer? Entity Layer (for ApplicationUser)? I don't want to create a dependency on my DAL regarding the DBContext so how would I supply it to the OwinContext?
3) I would like to use different DBContexts but I'm wondering how I'd make navigation properties to my User to the ASP.NET Identity user, vice versa etc.
Are there example projects I can download that implement multiple DBContexts or combine preexisting DBContexts with the ApplicationDBContext?
Thanks!
Eitan

ASP.NET MVC Database Access Layer

Since I am new to MVC I have a few questions about the database connection.
I am trying to build an MVC application, and so far I have built 2 layers: Model(where my classes are, without any functionality) and Business (there is the functionality for my classes, every class has its own Business class) and there is also my MVC application. Both these layers are separated from the MVC project, I use them as ".dll-s". I am also using the repository pattern and the dependency injection is done by Unity.
Now comes the tricky part (or at least it is for me). I want to bind my application to a database. Most of the tutorials I have found rely on Entity Framework, but I don't want to use it, I want to use ADO.NET (Entity Framework makes me feel like I am giving my "power" away, so I want to manage the SQL on my own). So what is the best way to do it? How can I access the Web.Config from outside and read the connection string (or should I take care of the connection string inside the data access layer)? Is there any best practice how to manage the connection from "outside"? I mean I could easily just create a dbaccess object inside my MVC application, but I don't want that. In the MVC application I just want to use my business(object) classes.
And one more thing. What is the best practice for DataAccess: to build a new layer, or is it also fine to include the functionality inside my business layer? I am more tending to build a third layer, so I can reuse this code for any other application but maybe there are some other approaches.

You can create another project called "DAL" to handle your data access layer which is built using pure ADO.NET. You will add a reference to the entity project so that you can return these entities from your Data access methods. Now from your Business Layer, Add reference to the Data Access projects so that you can access these data access methods from the Business layer classes. From your MVC project, Add reference to your Business project ( and entities project if you are using those entity objects in your MVC project). In this way your MVC project do not have any idea what data access technology you are using.
You do not need to have connection string in your DAL project, Keep that in your UI MVC project and your DAL project will be able to read it as long as you have the proper references added between these projects.

Entity Framework Multiple Database Project Structure

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.