I currently develop with Django, but want to be ready when a future client inevitably requests a site done in ASP.NET MVC. While most of the structure and flow of ASP.NET MVC is more or less identical to Django and RoR, the one part I'm not sure about is the Apps methodology Django employs to make code reuse easier.
Is there an equivalent to Django apps in ASP.NET MVC? That is, can I create a feature, like tagging, comments, calendar of events, simple blog, etc. and bundle it up, making it portable to other projects with a minimum of glue code required to integrate it? Perhaps some kind of plugin or module system?
Django doesn't follow the traditional MVC pattern, since they advocate that in the Web world, their MTV is more suitable. In the overall, I prefer Django over Rails because of the django apps. You can do almost the same in RoR with the Rails vendor plugins, but it's not the same.
ASP.NET follows RoR structure, and therefor you don't have the reusable apps. If you check the folder structure in a MVC project, you don't even find the RoR's Plugin folder, so I bet you should do it VisualStudio-Like.
Create a reusable app, as a separated project, include references for that project in your main one, and in your Route file, just redirect to the other project's controllers.
This might be of interest as well: App Areas
we've tried to do something similar, albeit from a different angle. we use compositional controllers for increased reusability in bistro, and an ndjango as the templating language. what we start to see is controllers become more granular, and as a result less dependent on where they reside - more componentizable.
Related
I wanted to build a VB.net web application using MS Visual Studio 2015. Someone suggested me to create a Web API instead of MVC project if i'm also planning to create a mobile app later on. I may use angularjs in my project so controllers will surely be used, so what should i choose when creating the project in the first place?
Because when i created a web project: File=>New Project=>ASP.net Web Application=>Empty..there are no folders for Controllers, Model, etc. Do i have to create a Controller folder on my own?
Or should i do this: File=>New Project=>ASP.net Web Application=>Web API..? sorry if its a silly question. its just that i'm afraid that if i chose the wrong project now, it'll affect the development later on.
Answer to your question mainly depends on your choice and needs,
for example
In Case of an empty project as name defines you will have nothing else web.config.
Benefits of it:
here you can define, design your own structure. you can either make
it simple 3 tier or you can make it WEBAPI application. it's all up
to you.
however in the case of choosing Webapi template you will have a prebuilt structure which can help you out for initial understanding
https://docs.asp.net/en/latest/tutorials/first-web-api.html
benefits of it
You will get predefine template and structure.
you can utilize of webapi's which further isolate you backend logic from the frontend.
as you are also planning to create the mobile app. and using front end as angular, so in that case, webapi may come handy.
as the whole world is moving towards webapi, so i will recommend you to use it. please refer https://blogs.msdn.microsoft.com/martinkearn/2015/01/05/introduction-to-rest-and-net-web-api/
so down the line it all depend on you if you want to build you application for the stretch and take full control of it regarding structuring backend etc.. then go with empty else go with Microsoft pre-define template
Thanks,
Ajay Kotnala
First time asp.net webAPI + angular project. From many examples I've seen online I've found there are basically two ways for handling the views.
The first (which I have seen in many tutorials and courses) - use APIcontrollers only, so that the view are generated by angular. That means my project structure would have a folder 'app' and it will contain the html files (probably inside a 'view' folder). The routing will be done using angular routes. I will only have APIControllers in the project (without the regular Controller object).
Example project: https://github.com/DanWahlin/CustomerManagerStandard
The second - using Controllers to generate the views, using Razor (cshtml files), and angular incorporated into those (i.e ng-click inside the cshtml). There's no special 'app' folder for angular etc.
example project : https://github.com/Wintellect/Angular-MVC-Cookbook/tree/master/CRUDOperations
So, I'm wondering what are the pros and cons for each method, and when shall I use which one. Examples projects would be great as well.
I can only assume that the first method is more modular and differentiate server and client. However, using it means I'm loosing razor (Do I even need it?)
Thanks!
I actually had to make this decision a few months back myself.
This comes down to what you feel is more comfortable. I chose to do angular and WebAPI controls only. It makes me think in terms of true separation of concerns just easier, angular is your presentation layer and webapi is your services. This also gives you the freedom to do the compression/formatting of the actual html pages(instead of the cshtml pages which you really have no control over).
One more pro for WebAPI only is scalability, you would really only need one webserver for the webpages but you can scale out your WebAPI, this will allow you WebAPI to be your api as well as your clients as well.
Razor is just a view engine and in my experience angular does a good job of templating and directives to bear the cost of losing razor. You'll probably end up writing pure HTML in your razor files anyways once you get a hang of directives which means you'll have more of an issue adding a new view. Who wants to create a new controller, new action and a new view, and then have to do that in angular. It just ends up being easier and less complex to let server serve the html files, and let angular do all your routing and logic for you.
I believe too that the html files get cached too so you will see less round trips as you navigate page to page in angular.
As a person who works at a Microsoft shop and loves AngularJS for nearly all my front-end, the sooner you get away from mixing Razor and AngularJS, the better, especially if you are going for a SPA.
The only time I would recommend using Razor at all would be to generate the landing page (and possibly login page/admin area). It does give a nice way to provide authentication to access the app and then use Web Api Authorization attributes to do the rest of the authentication.
I am working on an web application/site and I want to do it with AngularJS, ASP.NET and Typescript.
I read about the Single Page Application concept, but I still have some question about this whole concept:
Why should I prefer a SPA (Single Page Application) before multiple pages.
I also have some questions about integrating it with ASP.NET:
In ASP.NET it standard generate a nice bootstrap layout with about 3 pages at the top. So I think that it means that I need to combine all these pages to one page. But how can I get it to work together with the routing of ASP.NET. Because you will use the routing of AngularJS, and I want to keep the login from ASP.NET (Can you maybe give an example so I can see how it works).
If I got it correctly Typescript in this concept will replace the JSON webservice. Is this correct or do I got this all wrong?
If you could answer one of my questions I would be very thankful.
SPA's are a trend, they are mostly useful to move the load on your server to the clients. Only data requests will be made to the server, rendering is done on the client machine.
There are still other benefits, but I guess this is the most relevant.
As to your questions regarding integration into ASP.NET.
Building an SPA does not mean all has to fit in one page. Look at AngularJS, it will fetch views as separate requests (see templateUrl in routingprovider). That being said, you can use ASP.NET MVC and serve ASP.NET Views as Angular Templates. This allows for a neat separation of Model, View and Controller parts.
Typescript is Microsoft's JavaScript dialect. It will not replace JSON and you will probably want to use JSON to exchange data with your server. You could use XML, but that is a little bit oldfashioned (and way more bulky).
I have no experience with TypeScript so I would not consider doing that (coffee might be a better alternative), but there are also some quicks in JavaScript you need to be aware of. I would suggest to search Douglas Crockford and Javascript on Youtube. The guy has great talks that can make you a JavaScript pro.
Has there ever been a more confusing/difficult time to be a web developer using the Microsoft stack? That's not really my question... I know that the answer is a categorical no. :)
The single page app template that comes with VS 2013 is deplorable.
I've been working on building up a similar project template that uses Angular JS on the client, but I'm starting to spin my wheels a bit porting over the external (openId/oauth) login features.
I believe this is because of the lack of good, single-point-of-truth, and current documentation for Katana's auth/security bits and also because of how unreadable the client side code is in the S.P.A. template in visual studio 2013.
I know that I can get through it, but while I'm struggling with it, I'm wondering:
Are there any good community provided project templates or example code bases in existence that use .NET 4.5 (MVC5/Web Api 2), Angular JS, the new ASP.NET Identity stuff, and the Katana packages?
There's HotTowel.Angular, but it takes no stance on security. Besides, it's a Nuget package, which can't or shouldn't dictate as much as a proper project template can.
I agree with your observations. I have found the following setup that seems to meet your requirements and I think works very well (I don't have a template), I would suggest the following:
Create an empty WebApi2 project and adopt authentication/authorization depicted here
Use a regular index.html in the base directory as a launching point for your angular application. You can either maintain your client packages with nuget, npm, or bower.
Use whatever technique you like for organization of client code.
Personally, I would create 3 projects, One for client code, (mydomain.com) One for your api (api.mydomain.com) and one for your Model/Repository/Data Access layer.
update
Here is an open-source project that might be what you're looking for!
I was curious how in the typical ASP.NET MVC mentality one could build a platform that others could develop plugins for. I mean, how would those plugins look like?
Like exiting user controls for WebForms, encapsulating all layers in themselves, or three different files representing the model the view and the controller. I should develop the core of a CMS, that I'd like others to build plugins for later on. Which mentality is better for that, classic Web Forms or ASP.NET MVC?
I need developers to be able to separately build components for that. Is it possible to encapsulate the MVC directory structure in a component DLL file and then when I reference the DLL file, to be able to directly access the component's model, view, or controller as part of the general MVC structure?
The most promising component techniques have come from the guys over at lostechies.com and Mvccontrib in the form of Portable Areas. Portable Areas allows an entire MVC app to be appended onto an existing application. So its not just a UI component but also provides all the work flow and screen integration as well.
Open Forum does something like this as well. I don't know how, but it is very plug and play.
For straight up plugin architecture there is an interesting screencast and source code for Rob Connery's link text. He takes advantage of the App-Code directory to slide new plugins into place without having to edit the main site.