Home
Angular Code Distribution
Objectives
I have seen many different opinions about code distribution in a proyect. In this case I would like to present one more option to those out there. I would like to present the two basic ones and another option in order to make a comparison on each case.
First case
We can see that the most common code distribution for simple projects is this one.
The project in this case will be an angular module that will be in app.js. We can see that there will be some controllers, directives, filters and services associated to the application module.
This is a very fast approach for solving simple things and in order to bring some learning is a good approach too.
How much of this are we going to reuse for other purposes? Well we can reuse things like directives / services / filters... inside of the project.
Second case
This is another approach of an angular project, separated by modules of the application.
This project have modules related to different parts on the system, making a separation of concerns in modules.
This approach is an interesting one, as playing around with a module will affect that module if there is less coapling and high cohesive code.
How much of this are we going to reuse for other purposes? Well we can try to have some things in commons for those things we could reuse inside the project.
Third case
This is the another approach. We can see the following folder structure.
Login and Posts are modules. All the services and directives too. Why?
Well when we try to solve a problem for a proyect in this case we can think on the type of problem we have.
So when solving a problem related in an organization level for example a directive that could be use in other proyect we can go to the module of directives and add one more solution there.
Lets say our manager says, we need to reuse some of the things on the business rules you are applying here to another proyect. Then we can think on our service module a reusable unit.
In the case we really feel that those cases on reusability could happen, then it would be a matter of creating a another repo for services or ui directives adding versioning to those products. Services and UI directives would be vendors for other projects.
This is a nice approach on thinking to create a foundation that would be and homogeneus solution accross many projects.
Conclusion
So there are different approach's related to how code distribution could be. The thing is to get the best code distribution for each problem
We can see that, thinking on what to do is how much do you want to reuse and why for each case.
Home
Travis CI
Did you like this post?
Share it in twitter
or
follow me!
Objectives
I have seen many different opinions about code distribution in a proyect. In this case I would like to present one more option to those out there. I would like to present the two basic ones and another option in order to make a comparison on each case.
First case
We can see that the most common code distribution for simple projects is this one.
The project in this case will be an angular module that will be in app.js. We can see that there will be some controllers, directives, filters and services associated to the application module.
This is a very fast approach for solving simple things and in order to bring some learning is a good approach too.
How much of this are we going to reuse for other purposes? Well we can reuse things like directives / services / filters... inside of the project.
Second case
This is another approach of an angular project, separated by modules of the application.
This project have modules related to different parts on the system, making a separation of concerns in modules.
This approach is an interesting one, as playing around with a module will affect that module if there is less coapling and high cohesive code.
How much of this are we going to reuse for other purposes? Well we can try to have some things in commons for those things we could reuse inside the project.
Third case
This is the another approach. We can see the following folder structure.
Login and Posts are modules. All the services and directives too. Why?
Well when we try to solve a problem for a proyect in this case we can think on the type of problem we have.
So when solving a problem related in an organization level for example a directive that could be use in other proyect we can go to the module of directives and add one more solution there.
Lets say our manager says, we need to reuse some of the things on the business rules you are applying here to another proyect. Then we can think on our service module a reusable unit.
In the case we really feel that those cases on reusability could happen, then it would be a matter of creating a another repo for services or ui directives adding versioning to those products. Services and UI directives would be vendors for other projects.
This is a nice approach on thinking to create a foundation that would be and homogeneus solution accross many projects.
Conclusion
So there are different approach's related to how code distribution could be. The thing is to get the best code distribution for each problem
We can see that, thinking on what to do is how much do you want to reuse and why for each case.
Did you like this post?
Share it in twitter or follow me!