ASP.NET 5 , wanted to separate entity framework from Web Project - asp.net-core

I'm trying to achieve below application structure
App.Model
-- UserModel
-- OrderModel
App.Service
-- UserService
-- IUserService
App.Entity
-- DbContext
Website
-- WebAPI
-- Invokes Service
Most of ASP.NET 5 application examples , initializes entity framework in startup file of website. like .AddEntityFrameowrk() .. etc.
Need to know how we can separate the Entity into separate project and how do we initiate the DBContext if we are invoking repository from Service project.( since startup file is not available for class library)

In previous projects, I have taken the approach of maintaining multiple ASP.NET projects in one solution (or multiple solutions). This will give you the ability to remove the EF dependencies from your web application and have the web application talk only to the API which handles all the EF
In the past, I've created a dedicated 'domain' project which contains all the models and can be referenced by both your web application and API projects.
So the project structure would look like this
Domain project: Contains only c# classes that represent your model. Start with an 'empty' project
API: Contains your web API. Uses EF to interact with database. I would personally scaffold the APIs fro your model but that is a personal choice. Right now, in ASP.NET core 1.0 RC1, the web api template is poor so I'd start with the full 'web application' one and remove all the default views, controllers, scripts etc. References the domain project so that you can scaffold your API controllers from the model
Web Application: Your main web application project. Start with the 'web application' template but use HttpClient I your controller to use the api for data interactions. In the past I've created a set of static 'api helper classes' to make this task easier but that is a personal style choice again. References the domain project so that you can convert incoming JSON responses to the full .net model

Related

Can I have asp.net core mvc and web api as single project

We want to build an asp.net core web application. it contains MVC part for returning Views and API to return JSON and have Restful services for our web application.
So can I have MVC and Web API inside the same project? as currently when i want to create a new project inside .NET 6.0 i have to select the either MVC or Web API type :-
So can I have MVC and Web API inside the same project? as currently when i want to create a new project inside .NET 6.0 i have to select the either MVC or Web API type :-
Certainly you can. What all you need is, you should have one solution. Furthermore, within the solution, you ought to create two project. One for MVC application and another for Web API application. Here is the simulation how you can achieve that:
Project Architecture Would be Like:
If you want to run two project together:
Go to your solution and right click on it
Select Property
Choose Multiple Startup Project

Best practice for where to place Services folder in C# Blazor Web Assembly (ASP.NET Core hosted) application?

Where is the best place to create a Services folder in a C# Blazor Web Assembly (ASP.NET Core hosted) application? A Web Assembly (ASP.NET Core hosted) application has 3 projects for 1. Client, 2. Server and 3. Shared.
My initial thought is to place the Services folder in the root of the Shared project. Is there a best practice of where the Services folder should be placed for this kind of application, maybe in the Server project for example?
I have created a Service to read a CSV file which I have registered with the Dependency Injection service to make it easier to access throughout the project and also for testing. I will be adding other services as well so would be good to know if anyone else has a preferred place to add those services normally?
Thanks for your time.
It's important to understand what is sent to the browser and what is kept on the server-side. The Client project has reference to the Shared project (by default), so once compiled both projects Client and Shared will be sent to the browser (as .dll). The Shared project is also referenced by the Server project, and it acts like a "bridge", holds some common constructs. Having that said, I'd suggest you do the following:
Client project - You place all your client-side logic, your razor components, your views, and the code that calls various API endpoints (or it might be gRPC calls).
Server project - Here you keep all your API endpoints and back-end services.
Shared project - Since this is referenced by both, a copy is sent to browser, and another one kept as part of your server application. This is a good place to put all your Dto models. Avoid placing any services or any logic-related constructs. The common constructs between Client and Server are the models only. Having a shared project is just a convenience, you can of course opt it out completely, and duplicate your models in both places.

Web Application vs Web Api project types in Asp.net Core

I know that Asp.Net MVC and Asp.Net Web API were merged into one code in Asp.net Core and they inherit from Controller base class and can all return implementations of IActionResult. it be a View for MVC or Json for web api.
But when i want to create a Asp.net Core project, it offers two templates (Web Application and Web Api ), according to what i said in above, there is no differences between these controllers, why there is two templates? is there any differences that i don't know about it?
The web application template will create folders and import stuff needed for a web application such as jquery, css etc. Web api template will create folders and import stuff for a web api. Also the controllers created by default will have different implementations, for example, web application will be returning views and the views will be created in the appropriate folder.
So although they derive from the same controllers, each type of project requires different dependencies.
If I were you I would go ahead and create one for each type and see the difference.
If you want to have both web api and web application in the same project, use areas. This way your web and api will have separate controllers, folders and models. Also if you want to separate them in the future, it will be easy to do so.
The difference between 2 templates is-
The WebAPI template starts with a Controller class that will allow you to respond to RESTful requests at the /api/Values endpoint.
The Web Application template will give you an MVC framework enabled project with some Razor views, the bootstrap CSS framework and jQuery library installed.
If you want to create project with both MVC and API controllers then I would suggest to go with ASP.NET Core Web Application template and add require dependencies.

Need advice about using repository pattern in an n-teir application

I have a web application that is developed using ASP.NET MVC.
The application follows the nth-tier architecture, and I have divided the application into 4 different project which are Model, Core, Framework and the web application.
The Model, Core and Framework are DLLs, the Model contains just my POCO classes, the Core contains my DbContext, repositories and Unit of Work implementations while my framework project contains classes that would be used directly by my MVC web application such as action-link extension, custom view engines e.t.c.
In addition to my framework I created a class called service which makes method calls to the repositories in my core DLL and method in the service class are called by my web application.
My question is: Is it ideal to channel method calls from the web application to the repository through my the service class in my framework DLL or just make a direct call to the Core DLLs?
Don't add an abstraction layer unless you require it. If you don't have a strong reason to add a service layer in the middle, you will end up implementing the Poltergeist anti-pattern, where sole purpose is to pass information to another object.
In general, calling your repository directly is perfectly fine so you have to analyze if you foresee any particular restriction disallowing this schema.

ASP.Net Web Project Deploy with Database Migration at Different Project

Our solution contains (basically) 3 different projects.
Web Api
MVC
DbCore
Domain
Web Api and MVC projects are (as you can guess) web projects and DbCore and Domain are Class library projects.
DbCore contains Entity Framework definitions, configurations also migrations.
Web Api connects DbCore through Domain.
This infrastructure works well but i want to deploy and apply migration db while deployment. But deployment wizard doesn't show me option about that because web projects don't contain any DbContext definition.
How can i achieve this?