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
Related
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.
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 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 am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
Over time, the code base I maintain has grown exponentially. We have a variety of different utility classes, webparts, event receivers, console applications, and more.
Typically, each webpart lives in a separate DLL (one solution and one project per web part). Our utility classes have also been largely separated out into their own separate DLLs (this includes any specialized list access classes that get grouped with their beans together in a DLL). This has led to a large amount of solutions which has become more difficult to maintain (upgrading each solution to Visual Studio 2008, or simply just trying to find out the maze of DLL references).
With my discovery of the SharePoint Guidance, I'm re-evaluating our current code structure. For example, it looks like they recommend combining all of your specialized list access classes into a Repository (we've done completely the opposite so far by splitting them into DLLs based on what "solution" the code is for).
Questions: How should I be organizing my code? How do you decide what goes into a solution vs project vs folder or what goes in a namespace? One solution per web part?
I usually organize my code by functionality. Let's say I've got an extranet project and some code for some intranet webparts, I seperate it out into a Extranet and an Intranet project, and seperate the different classes of code (eventreceivers, timerjobs, webparts, etc.) into different namespace.
That way, I can deploy (sub)sets of functionality to different farms if I want to, and when editing code I got everything that depends on one another in the same place :)