3 Added point 6 about project life time.
source | link

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller); but and the Web services are different: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. (That could mean interoperation between many different platforms and languages as one "solution"). By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

  6. Like [5], how many platforms and languages are you working with over the lifetime of the project? You might find that in 5 years, your company wants to move away from C# on onto NodeJS/Go-Lang. You're building new areas to this collection of systems. You simply create a new project, which is deployed to its own (set of) subdomains (or virtual folders), and with the magic of web standards you can interoperate. You're still using HTML/CSS/JS on the client side, no user sees the backend. So even if you start with a single "solution" with a single "project", you should not be closed to federating to additional "projects", in fact such a closed-minded approach can work against you.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller); and the Web services: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. (That could mean interoperation between many different platforms and languages as one "solution"). By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller) but and the Web services are different: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. (That could mean interoperation between many different platforms and languages as one "solution"). By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

  6. Like [5], how many platforms and languages are you working with over the lifetime of the project? You might find that in 5 years, your company wants to move away from C# on onto NodeJS/Go-Lang. You're building new areas to this collection of systems. You simply create a new project, which is deployed to its own (set of) subdomains (or virtual folders), and with the magic of web standards you can interoperate. You're still using HTML/CSS/JS on the client side, no user sees the backend. So even if you start with a single "solution" with a single "project", you should not be closed to federating to additional "projects", in fact such a closed-minded approach can work against you.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...

2 highlight the ability to have multiple languages
source | link

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller); and the Web services: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. (That could mean interoperation between many different platforms and languages as one "solution"). By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller); and the Web services: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller); and the Web services: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. (That could mean interoperation between many different platforms and languages as one "solution"). By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...

1
source | link

There can be many reasons for separating or combining projects. I often have this struggle in my mind which way to go, but I have summarised the decisions down to the following:

  1. Is the main application: MVC (Controller); and the Web services: RESTful (ApiController). Those are separate routing systems and it's easier to maintain if they're separate projects.

  2. Isolation from deployment error. If you only want to change a CSS style in the main application, why should deployment also affect so many other parts of the system? This is a good reason for having static HTML resources separate from dynamic page generation and web apis.

  3. Do you want to avoid CORS configuration? Perhaps you don't like using Virtual Folders, in which case separate domains or subdomains would be needed for each separate project. I don't think this is a single reason for combining projects but certainly, a factor to consider.

  4. C# and EF take a while to "warm up". Unless you spend time on ngen, EF query caching, and code to "test" endpoints and manually "warm up" code endpoints, you'll find a very large monolithic project to have a longer first-webrequest delay.

  5. Modular / IoC / Solid Principles. The web is modular already, where a URL can take the user to a completely different server. By having separate projects, one limits the coupling (or at least makes it very visible), and thereby makes maintenance, extension, and rebuilds easier and modular in the future. If project A, and B, are working and you want to build C, who cares what stack or language A and B are. It does matter though if it's a single monolithic project.

Of course, all the points above depend on the scale of user-base and size of the project. If it's "Hello world" for one person, it would be overengineering to have IoC, Separate Projects, JWTs, etc...