This is exactly what I've had to do to introduce angular into an existing
MVC application. I've come across the following cons to using this approach:
1. It can be difficult to extract route values from the URL, for example if
the application uses restful URLs (e.g. /Mysite/{UserID}/Profile) then it
can be a bit of effort to extract the UserID parameter. You can create a
service to parse the URL but then it means the structure of the URL and the
angular application are closely coupled (which isn't good design). You may
think that this can be solved using angulars $location however this isn't
fully supported in IE9 or lower so depending on your browser support
requirements I would recommend producing a quick demo to check if it works
before implementing it in production code.
2. It can be just as difficult to work out the url to server endpoints if
they are restful. In my application I let the server generate the URLs to
fetch data and then injected them into the angular app like in the next
point...
3. My application was based on ASP.NET MVC and passed data to the aspx view
using a model. In order to get this data into angular I ended up writing an
inject method which took a list of args which then got added to the
$rootScope object. This meant that any controller scopes also had these
values by default, however they do effectively become global variables so
try avoid injecting too much. In order to add to the rootScope I had to use
a module run block:
function injectRootScope(args) {
currentApp.run(['$rootScope', function ($rootScope) {
$rootScope.args = args;
}]);
}
4. As for one app per page instead of a complete single page application,
you just have to be careful not to tie common services, directives or
filters to a single module/application. I wanted to make sure each
controller, directive etc. could be placed in it's own file but still be
available to use in any module. The only way I could get around this is to
ensure every angular html page has a js variable called currentApp, then
when loading controllers instead of writing something like
"angular.module('MyModule').controller('MyController'...", I set the
currentApp variable to 'MyModule' and then add controllers, directives etc.
to the currentApp
Also as a side note be careful of bundling tools such as combres when
adding the angular scripts to your page. I've found that some files,
especially already minified files, get malformed when processed by one of
these tools resulting in hard to track errors.
Hope this helps, implementing angular to my MVC application was pretty
painless after getting over these problems.
Cheers, James
On Wednesday, September 24, 2014 4:48:36 AM UTC+1, bnewton wrote:
>
> I’m embarking on my first AngularJS application and had a few questions on
> how I was planning to build this application.
>
> Would it be considered bad Angular application design by having each page
> basically being it's own angular application? In this structure the
> server-side framework would control the routing, user authentication &
> authorization. Each view in this application would contain it’s own ng-app.
> While there would be page refresh inbetween pages, but all actions on an
> individual page would be controlled by Angular.
>
> Would this type of application structure be a bad idea? Any pros and cons
> I should be aware of in this application structure? Or should I strive for
> the true single page app and leaving the server-side frameworks only do the
> API.
>
> I would greatly appreciate any opinions, resources or feedback on this
> topic. I just want to make sure I'm making the right architecture decisions
> for my application.
>
> Thanks,
>
> bnewton
>
--
You received this message because you are subscribed to the Google Groups
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
