CODEWITHSUNDEEP
asp.net-mvcasp.net-web-api
chobo2
chobo2

Reputation: 85835

Same Project Solution or New Project in Same Solution - Asp.net MVC / Web Api?

I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.

In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.

I am not sure if I should

a) Make a new area in my web api project and build my website from there.

b) Keep it in the same area and just make some new controllers and such in the web api project.

c) add a new asp.net mvc 4 project to my web api solution project.

Upvotes: 4

Views: 2908

Answers (4)

Kevin Coulombe
Kevin Coulombe

Reputation: 1575

Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.

Arguments for having a single project :

  • Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.

  • Many settings are shared between the two projects so we have to copy them in both web.config files.

Arguments for having multiple projects :

  • They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.

  • It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.

  • It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.

If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.

Upvotes: 0

DalSoft
DalSoft

Reputation: 11097

K. Scott Allen ‏recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.

I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.

http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx

Upvotes: 2

Prasad Phule
Prasad Phule

Reputation: 478

absolutely,

go through link http://efmvc.codeplex.com/

which is the best architecture to develop the big apps

may this one is help you...

another BEST one MVC N-Tier architecture

MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)

which you create this in same solution and build the app...

Upvotes: 0

Chris Pratt
Chris Pratt

Reputation: 239400

Definitely two projects. In fact, I'd actually recommend three projects:

  1. MVC website
  2. Class library, for sharing your DAL/Service layers
  3. Web API

Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.

A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.

Upvotes: 4

Related Questions