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.
Related
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.
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 am writing an ASP.NET MVC application that combines a set of features from existing applications. The new application is suppose to use UI features and logic created (especially for this purpose) in the existing applications.
For that reason I wanted to create in the existing applications some kind of a "blackbox" that I will be able to drop in my new application along with a matching connection string, and it will work independently, binding data on it's own.
I thought about using partial views, but I am having trouble with passing the model data to it, since the controller of the new application should not know about the model of the existing applications.
I can not use ASP.NET WebForms, since my application should be a "postback-less" application, and ASP.NET AJAX toolkit or frameworks alike are out of the question.
Any help would be greatly appreciated.
Thank you,
Katie
Portable areas might help.
I currently have a web application written by ASP.NET MVC. Now I want to add a web service so that some people can easily build application upon it. Shall I just create the asmx in the MVC Web project or create another project referencing to the Model project? And what's the pros and cons?
Thanks in advance!
Easy decision - if your MVC Web project depends on the web service at all, keep it in the MVC Web project. If not, create a separate project for the web service with reference to your model.
Keeping projects seperate allows people to read and understand your code more effectively. If your service makes use of your model, but is not part of that model, than it should definitely be a standalone project with reference to the model. This is clean design.
for my opinion I would do something like this in my solution
solution.Model -- the model that reflects your db,
solution.Repository
solution.MVC -- your model will be the refined Model, referencing the solution.Model
solution.Test
solution.WebService -- referencing solution.Model
I keep my Model outside my MVC Web application and just put the refined ViewModels in my MVC Model folder. I don't know much about pro's and con's but this is just a better way of doing it for me.
Doing this, you can use your Model anyway you want. Maybe you want to use it for WebService as what you ask. Or for another Application. You just reference your Model project to other projects that you need them.
I would look for Odata -> WCF Data Services formaly know as "Astoria".
If you are using for example linq-to-sql or EF you can make your data in a restful manner availale and provide a basic api...
You can define your endpoint like you do in WCF because the underlying service is based on WCF. And I would use a different namespace...
Website
http://msdn.microsoft.com/en-us/data/bb931106.aspx
Beginners guide with videos
http://msdn.microsoft.com/en-us/data/ee720180.aspx
open data format
http://www.odata.org/
I have an existing ASP.NET website with some custom routing, within a Solution that also contains Business Logic projects.
I want to create a new project within the Solution, which is an ASP.NET MVC website.
This website will also call the Business logic, and the ultimate aim is to port most of the code from ASP.NET to ASP.NET MVC.
But I want them to both work side-by-side for now, to ensure minimal down-time, as it's a high-traffic website.
Is it possible to accomplish this somehow using either ASP.NET routing or some kind of IIS setting?
Yep, you just need to add some routing to your current application. Try http://www.packtpub.com/article/mixing-asp.net-webforms-and-asp.net-mvc
Please have a look at this post by Scott HanselMan.
It provides detailed discussion about this along with a nice walk through.
I just wrote a blog post on this. It is possible. You might find it easier to simply relocate your web forms from your existing web forms project to your new MVC project. You may not have to change any code.