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?
Related
I created a solution with 4 layers which its names; Api,Entities,DataAccess and Services. Now I want to add MVC project to my solution to see my datas simple web interface.(I am planning learn Html and Razor).
Api layer is ASPNet Core WebAPI project(with api controllers and CRUD processes) and the others are .Net classlibs. How can I add MVC project for views and how can I use my api from this MVC project?
Right Click on the solution in VS2019 and add project > Add Asp.net core web app. Select the right framework version, authorization if you want to use it later on.
To run multiple projects to gather on VS2019.
Right-click Solution > Set Startup Projects > Choose multiple projects > Choose your API and MVC project as the start.
Make Sure the API project is on top to start it first before the MVC project.
In the MVC project you need to consume your API endpoints, by adding HttpClient or HttpClientFactory ( I recommend HttpClientFactory, google its advantages).
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.
I've been reading and learing about the new Worker Service features provided in .Net Core 3.0. I have been using this link from Microsoft: Background tasks with hosted services in ASP.NET Core
What I don't understand is this, can these worker service concepts be introduced into an existing ASPNET Web Project, like a Razor Pages site? Or must you create a new project and then deploy that project as a service using whatever mechanism the host OS proivdes for that?
Yes, you can host any number of hosted services (IHostedService) within ASP.NET Core applications. With version 3, ASP.NET Core uses the generic host (Host.CreateDefaultBuilder) which is the framework that is hosting these hosted services when the application starts. In fact, the ASP.NET Core web application is an IHostedService itself.
To add additional hosted services to your ASP.NET Core application, just register additional hosted services with your service collection, e.g. within the Startup’s ConfigureServices:
services.AddHostedService<MyHostedService>();
That service will then launch together with the ASP.NET Core web server when the application runs.
The Worker SDK that is mentioned in the documentation is actually a subset of the Web SDK that you are using with ASP.NET Core application. Microsoft.NET.Sdk.Worker is basically Microsoft.NET.Sdk.Web without the web-specific stuff like Razor compilation and wwwroot folder stuff. It basically sets up automatic file globbing e.g. for the appsettings.json and does some other useful things that the core Microsoft.NET.Sdk does not have.
Ultimately this means, that when you are using the Web SDK, then you already have everything the Worker SDK offers. So you do not need to specify the Worker SDK just to host additional background services.
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.
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