How to separate HTML files into a MVC architecture?

Question

I have an application that uses Angular.js, which I started using now and never understood how to apply the concept of MVC to a project.

I have two HTML pages, veiculo.html and index.html, both are named with the same name as "module" (angular.module) but use controllers different, all this is in the same file called controller.js.

All HTTP requests and routing to other pages are in this same file controller.js.

All this seems to me very pig but how do I separate correctly? For each HTML file there should be a "module" and a file controller.js different?

Answer 1

I recently broke my head too much to solve this same problem. I wouldn’t say solve, but find the best organizational/structuring method for my workflow (and my need for the moment).

1 - Structure of the project

The first step I took was to analyze what structure I needed.

• The entire project is free for anyone to access?
• There are restricted areas?
• Within the restricted area there is permission control?
• A visiting user can access only one specific area?

With this you can start from a basic layout structure and go incrementing along the project. The important thing is that you keep in mind that, in Angular, we can work with a well modularized project. Whether this module is yours or from third parties, the important thing is to have control of the files.

So in addition to a distribution area - files that will be placed in the hosting, for example, we still have the development files, ie the file with the raw code.

With this, we can start from a simple structure like this:

_RAIZ_
index.html
_dist //Arquivos que serão utilizados no projeto
    _view
        _noauth //views SEM autenticação de usuarios
            _home
                -home.html
                -home.min.js
            _empresa
                -empresa.html
                -empresa.min.js
            [..etc..]
        _auth //views COM autenticação de usuario
            app.html
            _financeiro
                -financeiro.html
                -fincaneiro.min.js
            _suporte
                -suporte.html
                -suporte.min.js
    _js
        _main //arquivos importantes pro app rodar
            -angular.min.js
            -angular-animate.min.js
        _vendor //arquivos de terceiros
            -ngMap.min.js
            -ngMask.min.js
        _app //arquivos comum a todo o app que você criou
            -app.min.js
    _css
    _img
    [..etc..]
_src //arquivos somente usados pelo desenvolvedor
    _app
        -app-ctrl.js
        -app-factory.js
        -app-run.js
    _view
        _noauth
            _home
                home-ctrl.js
                home-factory.js
            _empresa
                empresa-ctrl.js
                empresa-factory.js
            [..etc..]
        _auth
            _financeiro
                financ-ctrl.js
                financ-directive.js
                financ-factory.js
            _suporte
                [..etc..]
    _css
        [..etc..]

2 - Archives

Note that in the folders of dist, all files are already properly concatenated, compiled, etc. Ready to go to the project. They are also well segmented, by folders. Why do I use this way? I use this way, because I can make use of lazy-load, That gives me 2 positive points.

• My files get lighter as they are separated. The application loads faster.
• Increased security. The file will only be loaded if the user is authenticated, has permission and access the page.

Imagine you have the view financeiro.html, her duties financeiro.min.js will only be loaded when the user accesses it. Before that, there will not even be a call from this function. Another thing would also be the upload, because instead of having a file app.min.js 180-200kb, I own 2, 4, 5, 10 or whatever, 5-10kb files.

To do Lazy-load, there are some services, such as requireJs or the oc-lazyload.

Already in the part of joining the files, concatenate, do his uglify, I particularly use the Grunt. But nothing prevents you from using other services.

3 - Need for all segmentation

I won’t say that you should, or that this is the best way to do your project. Perform an analysis of the need, complexity and real gain you will have using these processes.

It is useless to segment so much, if in the end your project is simple, has 4-5 views, it is not necessary to be logged in. Or as much as you have more views, not all of them have several functions and you need to segment the entire project.

In simpler projects, it is perfectly acceptable for you to organize by type, for example:

_RAIZ_
index.html
_dist
    _view
        app.html
        _noauth //views SEM autenticação de usuario
            -home.html
            -empresa.html
            [..etc..]
        _auth //views COM autenticação de usuario
            -financeiro.html
            -suporte.html
            [..etc..]
    _js
        _main //arquivos importantes pro app rodar
            -angular.min.js
            -angular-animate.min.js
        _vendor //arquivos de terceiros
            -ngMap.min.js
            -ngMask.min.js
        _app //arquivos comum a todo o app que você criou
            -app.min.js
    _css
    _img
    [..etc..]

_src //arquivos de desenvolvimento
    _app
        _ctrl
            home-ctrl.js
            empresa-ctrl.js
            financeiro-ctrl.js
            [..etc..]
        _factory
            home-factory.js
            empresa-factory.js
            financeiro-factory.js
            [..etc..]
        app-run.js
        app-directive.js
    _css
        [..etc..]

4 - Modules

As for the modules, I would say that you do not have a barrier, or limit, or even restriction of use. Create a new module whenever you use a function that will require many files with many functions, where it would be very confusing to mix the others.

For example, I created a module auth where I coordinate user login and authentication. This module has 5 files: Ctrl, Directive, Factory, run and config. Each file has on average 5 to 10 functions. So it would be no advantage to join it to the other files, it would be very confusing.

Already a function of registering client, edit and delete, only consumes me 1-2 files (controller and Factory) with 3 functions each. In this case it is more feasible to use an existing module.

Just be sure to reference and initialize the module you created in your application. Otherwise, it’s okay to use a single module for the entire app.

Again, it will depend on the complexity of your project.

5 - Considerations

My recommendations for you to determine this flow would be:

Take a good look at your project, complexity and extension, think carefully before targeting content, it’s not always the best thing to do.

Segment when:

• Folders: Have more than 7-10 files;
• Ctrl, Factory, etc.: When you have more than 4-5 per file;
• Module: Create a new one when you need an elaborate function. Or that you know you can use in another project.

Reading references:

Project organization - A question that I myself asked here in the group and that yielded excellent explanations: Angularjs - File organization for large project

Guia Angularjs: https://github.com/johnpapa/angular-styleguide

I have used this guide for ALL my projects.

Grunt - 2 questions I asked in the English OS to use Grunt in large projects:

1- https://stackoverflow.com/questions/33804659/how-to-create-and-organise-config-and-register-grunt-tasks
2- https://stackoverflow.com/questions/33813073/task-not-found-using-grunt

There are many other great content out there, but I believe that with this you will get good guidance on how to proceed with project planning.

But don’t forget, do a good analysis before you assemble your structure. After mounting can be extremely stressful both compaction and magnification of it.

Note: This is not the best answer, much less the most correct one. It’s just the method that worked best for me.