I have an MVC5 application, which works normally. It has models, controllers, views, and all the other functionality. It is already a stand-alone app. I now want to create an API for this application. I don't know whether I should create a new WebAPI project in the same solution, or use my existing MVC project, to also include the API functionality there. Which is the appropriate way? Please note that later I want to use that API for creating a mobile application using Xamarin.
There is nothing wrong with using the same project, in many ways it makes the most sense as it will be easier when hosting the application if they live within the same web project.
I tend to keep my API controllers in a subfolder called "Api" which is neatly located within the Controllers folder of the web solution.
"Controllers > Api".
When i'm not sure with these kinds of things I tend to go with the simplest option, later on down the line if you find a good reason to locate the controllers in their own project for some reason this is easily achieved.
You mentioned that you will be using the API to develop an application using XAMARIN later on and this should not mean moving the API... mobile apps will not need any kind of reference to the API at all, they will simply be calling your application using standard HTTP requests. It will make no difference and again as you are going to need a host for your website, you might as well use the same host for your API too.
If you want use WebAPI not only for WebSite - SO sure, you have add new WebAPI project in solution
(+ it's better in OOP) - it be easy to change.
Related
I am going to build an application with two different front-ends.
the first one is a website which I intend to build it with MVC5 and the second one is with Android platform.
Question:
what is the best practice to accomplish this goal?
should I make the WebApi in charge of working with the lower layers of my application and make call to it via Android and HttpClient (for MVC) or just make my website with MVC and find the specific needed APIs to be called by Android platform afterwards?
I feel something wrong with having a facade (MVC controllers) on top of another facade(WebAPI controllers) meanwhile I can not find any better architecture for these kind of software.
If to start with, you keep the classes with the functionality seperate from your MVC or WebAPI controller code, you can share this between the 2. It can be cleaner to put your Application / Business logic in a separate csproj all together, then reference from your MVC and WebAPI. This will also make it easier to test that code.
This then gives you the option of developing your app MVC first, test with users and get feedback (without spending time on APIs etc yet), and then build your API afterwards for android (using the same application code). You could also end up with both running on top of the API, which arguably would be a better long term place to be for maintenance and security. This evolutionary approach will tend to help you avoid over engineering your software.
I have developed some MVC applications by using Entity Framework code first approach and now I am developing a new application that will also use web services for mobile applications that we will create. So, I have trouble about the issues below. Could you clarify me please one by one regarding to the issues?
Which web service technology should I use i.e. Web API, WCF, etc? (I am using MVC5 and EF version 6 in my project)
Can I use the same CRUD methods for my web application and for web services? If so, which modifications should be made on the methods and on the other fields i.e. models, etc?
For a current MVC application where EF code first approach was used, is it better to create a new methods for web services or should the current methods be updated by adding ability to support also web services?
Thanks in advance...
I highly recommend to use Commands and Queries. It's covered in this and this articles.
The Command is simple DTO object, and it could be easily sent over the network. In this case you have control over the fields and behaviour you want to make public.
Because commands are simple data containers without behavior, it is
very easy to serialize them (using the XmlSerializer for instance) or
send them over the wire (using WCF for instance), which makes it not
only easy to queue them for later processing, but ot also makes it
very easy to log them in an audit trail- yet another reason to
separate data and behavior. All these features can be added, without
changing a single line of code in the application (except perhaps a
line at the start-up of the application).
Is there any way to hide the controller and action name completely in MVC.
(eg) localhost:81 should always remain same even on clicking any of the action in controller.
i.e., localhost:81/Controller/Action should not happen.
For what it's worth, you don't have to use the controller and action name in the URL. That's just the default. You can always define your own custom routes and make any URL you want hit any controller action you want. This is even easier if you use attribute routing, available in MVC5 or via the Nuget package, AttributeRouting, in lesser versions. This allows you to customize the URL for each action explicitly right on the action definition, which again can be any URL you want.
However, if you're truly looking to have just your domain as the only URL period, then #HadiHassan is correct in suggesting a SPA (single page application) architecture. There's many ways to go about this, so you'll need to just do some research to determine which set of tooling meets your needs best. At one point there was a project template for an SPA app in Visual Studio, it inexplicably disappeared for a time, and I believe it has now returned in the latest web tooling for Visual Studio. However, it's not hard to start from scratch.
You'll most likely want two projects, a Web API and a basic website project. The Web API is to provide your backend connectivity and is where you'll end up connecting to your databases and such, with something like Breeze to provide the connectivity on the client-side (your website project). There's alternatives here though, as you can also easily opt for a backend like a Node.js, which then wouldn't even require ASP.NET at all.
Since a SPA pretty much moves the entire application over to the client-side, you'll want to lean on a robust full-stack JS library. Angular.js is a popular choice, and has support for all the stuff like controllers, routing, etc. that you lose from a server-side MVC application.
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.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
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.
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
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...
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.
I have created a custom MVC Forum application. But I'm starting to think that although it works great as is, I'm going to need to get it to work within other MVC apps (In fact I have actually been asked that already).
What is the best way with an MVC app to structure/develop to make it as easy as possible to integrate into an existing MVC application?
Areas? Develop within a sub folder from the start? Or is it just you have to work through and merge configs/controller clashes if necessary.
No need to Config or ... . you only need to create ability in your Logon Model and it's Controllers. A complete example is in Asp.net MVC 4 which Microsoft has added more libraries for authenticate from other sites/profiles. Also the model has changed a few in properties. see this technology or download MVC 4 framework to learn it. it's easy.