I'm planning to create a website using ASP.NET Core 2.0 , Entity Framework Core, Angular.
I was planning to create one solution with different projects (core, data layer, UI ...etc ) however the client quoted "this is a bad idea, please create separate solution for your UI and API).
how can i create multiple solution and still let them interact with each others?
What is the best practice?
If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Solution is basically just a logical container for projects, so you can create multiple solutions which will reference the same (existing) projects. This is quite common for large solutions like for example Xamarin.Forms - you can have one large solution with all projects and then have smaller solutions for developers who need to work with only a subset of the projects.
You can add existing project to your solution by right-clicking the solution in Solution Explorer and choosing Add - Existing Project.
I think your client may misunderstand what a solution is. Grouping your projects in a solution only affects your workspace in Visual Studio, it does not mean that your projects have dependencies between them (unless you explicitely say so in their references)
The only way I can imagine this working is to deliver each solution as a set of microservices.
However, now your architecture is different. Only one of those solutions is going to be publicly exposed. The others will need to sit behind a firewall to ensure that they can't be reached by external users. But all of them will have scalability and security concerns.
So you'll have a set of data services that encapsulate Entity Framework and expose the data through a Web API, and a business logic API that is reached over a Web API, and then your UI (which should include Angular).
APIs calling APIs. Welcome to microservices.
how can i create multiple solution and still let them interact with each others? What is the best practice? If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Answer :
Create base solution first ex : BaseSolution.sln then go to that solution file explorer and create API,UI folder.
Now open visual studio and create new solution ex: ApiSolution.sln save it under API folder and add web api project inside ApiSolution.sln and save.
Now open BaseSolution.sln and right-clicking the solution in Solution Explorer and choosing Add - Existing Project then choose web api project from ApiSolution.sln then add it.
You can follow step 2 and 3 to create more solution and add it to BaseSolution.
Web api connect through HTTPClient with another web api.
Related
I try do my projects with clean architecture. I use Entity Framework. Everything is good and easy to know. I have structure like this - Domain, Application, Infrastructure etc. I create my project without any big problems - WebApi project. Now I would like to add Blazor server side project. What is the right way? Only add Blazor project to my existing solution? Here is few problems for me. I will have the logic of two applications linked (handlers). And I have some nuget packages which contains webapi specializations. When I create own solution for blazor app here is only one problem. The duplicate of dbcontext. I need "duplicate" (I can use only 2 tables if I need) domain project with entites and dbcontext in infrastructure. But then it work's good and it's clear. But I don't think it's good way to duplicate domain project. And where is stored migrations?
I know if projects will microservices it will be super clear and it's makes sense. But when I have monolith and would like WebApi and Blazor app with one database what's right way?
What is the right way?
As always - it depends.
In the Uncle Bob's article on the Clean Architecture the following point is present:
Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
If your Blazor App can be considered just another UI (without major changes to the business rules, though it can have some specific use cases) then it should be a part of the current solution.
I was Studying a course in PluralSight in clean-architecture by Gill Cleeren, they the Blazor project to the same solution
The point of Clean Architecture is that you do not have to duplicate shared logic. Blazor server project is a "front-end" layer at the edge of your application. If implemented correctly you will reference the other projects just like your WebAPI does.
Try to add a Blazor Server project to your solution and reference the Application/Infrastructure/Domain projects that already exist and you should be able to re-use all the exisitng logic.
Blazor (and WebAPI) is nothing more than a way to present your data, so keep it that way.
Context: I have a codebase that consists of an MVC project, WebAPI project and one web project in the same solution that was originally intended to consist of different websites for each of the functions / areas it has, for example within the solution there is a folder for the admin site eg views, service layer, repository etc, and for the customer site there is the same folder structure and files. The code in these two folders do not share the same service layer code and it is duplicated. I want to refactor the code for these two sites into a standard design and layers.
Question: What is the best approach for making these two areas appear as two separate sites in IIS? Currently there is only one site in IIS so it's not possible to have one running without the other. Would I need to make two separate web projects for these, refactor the code and then set the startup projects to multiple startup projects? Because knowing this will directly influence the refactoring of the two areas to use the same service layer logic and shared code.
Any pointers or suggestions on the design for this will be very much appreciated as I have not attempted this before having worked with only one web project within a solution and I would like advice from others who have worked with this type of design and refactoring to make multiple site nodes in IIS for areas/web projects in the same solution.
There's nothing wrong with having 2 or more web projects in a solution and building and deploying separately to IIS. You might have an issue debugging both applications at the same time in the same instance of Visual Studio, but that's easily resolved by opening another Visual Studio!
And this is a great book for looking at different solution layouts.
I've seen some good examples on github in the past too: https://github.com/thiagolunardi/MvcMusicStoreDDD
I've been trying to find some clear documentation on best practices with regard to nesting Visual Studio solutions. Please bear with me if the terminology is wrong - I'm not really experienced in creating significant solutions.
Here's what I'm trying to achieve.
I have a website that is a web application in VS speak - so it is my solution.
The site will have some reusable functionality. Normally I would just create a class library project and have done with it.
However, in this case the functionality is database driven via Entity Framework. If I was creating a self contained project, I would create a new solution, containing 3 library class projects for BLL, DAL and Entities.
So instead, I'm thinking a second solution containing the 3 class libraries - obviously I don't need a second front end as the primary web application will do the job.
So, I have a number of options as far as I can see:
Create a new solution as described above that can be plugged into my
main solution - but what do I do with the unwanted project that
contains the App_Data, Account folders etc?
Create a single class library and create visual separation through
folders.
Create 3 separate class lib projects (although this gives least
benefit)
Or, something else I'm not aware of.
Sorry if this sounds basic to you guys that do this day in day out, but I just don't have the necessary experience to make the right call.
I currently have an asp.net console application which simply retrieves a lot of data via an API from a remote server and, using Entity Framework, saves it into an SQL database. The application takes 3-4 days to run and I run it manually once a month or so.
The project is separated into a Models class, and a Repository class as well as the application itself.
I need to now build an ASP.NET MVC web application which allows users to view the data that has been retrieved and am looking for advice on how best to structure this.
Do I create a new ASP.NET MVC project in my solution and set that as the start up application, referencing the same Models and Repository classes? If so, how do I then run my console app? Or is it best to keep these as separate solutions, just referencing the same database?
Is there a better way of doing this as well? (ie, is there some way the console application can be rebuilt as being part of the front end and use queues or workers to fetch the data regularly?)
Thanks for your help,
Robbie.
Same solution. Different projects. By being in the same solution you gain the easy ability to reference shared components. I would actually recommend breaking out your entities, repositories, etc. into a third project, a class library, that then both your console app and MVC app will reference.
If you don't put everything in the same solution, then you're either stuck in DLL hell, where you have to build your project and manually copy the DLL into the other project, add the reference, and then keep everything up to date when you make changes in that DLL. The more projects that get involved, the greater the entropy and greater the likelihood that your projects all end up running on different versions of the DLL.
Another option is to create a Nuget package containing the shared components, host it in your own private repo, and then add it to each project that needs it. However, while it's pretty easy to set all this up, it's not 100% frictionless, and you will have to remember to repackage and republish the Nuget whenever you make changes, and then individually update the package in each referencing project.
Long and short, same solution is always the best way to go unless there's a very good reason not to. It's the only "it just works" approach.
Personally I would keep these as separate projects and separate solutions that just reference the same database, but move code that can be shared by both solutions into a separate class library.
The way your web application will present your modeled the data will most likely be very different to how your console application will use it; so using the same models and repositories will most likely further couple your web application to your console application.
This is very similar to the way micro services work, where the micro service acts and grows independent of its consumers (in this instance, your web application) and only communicate via a clearly defined API.
I have a scenario that i have never come across and as such require help. I created an Visual Studio Web Application. The solution had two parts.
Project that holds all the UIs and
a Model that contain my c# code.
The objective was to achieve a 3 tier architecture. The model being the middle tier. The project is running and everything is awesome. NOW! This is my situation and I dont have an idea on how to approach it. I have to build another application, which basically is an extension of the first one. So how I went about starting this was to add another WEB Project to my currently solution. This had a lot of problem. When I deploy the project two web pages would load (one from each project). What i want is ONE webpage to load and base on your userId it will send you to the appropriate location. What I also saw was the second web project i added needed it's own users. How it should be is.. one set of users each having specific access to the application (which ever part). I need input on how to go about getting this done.
What I want is to debug 1 solution (with the 2 parts/projects). Base on userId he/she has access to a specific project but there is one user list that governs the entire solution and not two list, one for each project.
Is there a problem just adding pages to a directory in the existing web project? Normally, separate projects would be deployed as separate applications, not as merged into the same application. You can control access using web.config files in the "secured" directories
Another Architectural suggestion would be to create a Main web project that was sort of a wrapper if these applications are extensive enough and functionally dissimilar enough to warrant separate projects. This would be where your routing logic would take place and would provide simple stub directories for your paths (user-type 1 ... user-type n). Then you can create a project for each of your end paths and set some build actions that take the output of the sub projects and copy them to the output directories for the wrapper project, but this gets pretty complex.
I would still recommend keeping this as a single project if it is to be deployed as a single web application.
While it's possible to make this work as two separate systems, it's really a lot more headache than it's worth in most cases.
The question you should ask yourself is, is it really worth it to do this? What are you gaining from it?
This article explains how to do this:
http://support.microsoft.com/kb/307467
Another option is to create sub-sites, which is to add your additional project as a child. This is described here:
http://abhighag.blogspot.com/2012/03/separate-web-application-into-multiple.html