Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm writing an app, which does OAuth authentication to several providers (e.g. twitter, facebook). I'm new to Angular, the UI / model is written in Angular without an issue.
But, I've got a lot of helper methods, e.g. callApi, checkVerification, getToken, etc. etc.
I think about 8 methods. I've been looking into creating factories in AngularJS, but I don't know why I should do this? It will require a lot of rewriting and I don't see the advantage? Why not keep it simple with helper methods?
A factory is just one way of creating an angular service. You can group your helper methods into these services.
Being a angular programmer and not using services is exactly like being a electrician and not using the ground wire, its not really needed for anything and saves time to not have to hook it up, but you are taking risks of starting a fire if some appliance has a short. In programming the risks are in terms of code flexibility, maintainability, and test-ability. If one of your modules does not work as intended, it will be harder to debug, etc.
When you have a significant amount of code, logical groupings of helper functions into services helps you more easily organize or find them and test them.
This best practice is suggested by many senior developers who worked on large angularjs projects and have had successful experiences by structuring code in this way. It provides another layer into which you may find you want to insert code later. If you don't have it in place, you won't use it (for the reason you just said, it will take you time to rewrite) and then your code will just end up messier and messier over time. A major feature of angular is to encourage code organization and test-ability.
Of course, you can write code any way you want that works, but using services (via factory or other methods) will help you not end up with large project that becomes a very difficult to maintain mess over the long term. Like other design patterns, very smart programmers have discovered coding structures and best practices that yield powerful long term maintainability benefits.
See: Why use services in Angular?
for more views on this.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
My goal is to fully understand the differences between a library and a framework
I have been able to have a basic understanding of the differences between the two. Except for one basic description that is commonly given out:
"The key difference between a library and a framework is "Inversion of Control". When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you"
programcreek.com
What does it mean for a framework to call you?
I have done research on what it means to call a function, method, etc. and now have a full understanding... But I am not able to comprehend nor find any information on what it means for a framework to call you
I have tried looking this question up with multiple different ways to frame it and all I am able to find is: MFC Framework how a framework calls your code. I am not able to find anything in the realm of languages or frameworks I am familiar with
Arguably any sufficiently complete library is indistinguishable from a framework. By inversion, any sufficiently thin framework can be treated like a library.
In simple terms, the more a library dictates how you code, what practices and conventions to follow, and how to organize your code, the more it resembles a framework.
The "inversion of control" is something that doesn't necessarily happen in a clean-cut way. Some frameworks are very light in that they don't force a lot on you, that you can yield control incrementally. Others dictate strict terms, that you either do it their way or you don't do it at all.
There's a huge spectrum here of framework-like-libraries and library-like-frameworks.
When a framework "calls" your code, it usually means that you've followed the patterns laid out by the framework itself and your code slots into pre-defined locations in that pattern.
That's not to say libraries don't call your code as well, they just impose fewer constraints on where, when and how that happens.
So here's a library call:
// Tell the library to perform a user registration
let user = FancyLibrary.registerUser(...);
Here's a framework-like structure:
// Start up the framework and ask for notifications if/when a particular event occurs
let app = new SuperFramework({
onRegistration: user => { ... }
});
Though there's often a blurry line here. Some situations are very clear, but there's a lot of toolkits that have strong conventions, even if they are libraries.
For an example of something that's sort of in the middle, consider Sequelize which is an ORM. Is it a framework? Most would consider an ORM to be similar to that, it has strong conventions and so on, but it's also a library that can be used to make simple SQL calls, nothing more. It's hard to say exactly what Sequelize is other than a robust toolkit that can be used to perform complex tasks.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am new to Node.js coming from a C#.net background. When coding in .net, I was use to using several of the design patterns to organize my code, service layer, repository, etc. When I needed to add logic that spanned multiple models, I could use services for this as well. Moving to Node.js and reviewing examples and sample code, etc. I do not see a lot of utilization of service layer, repositories, etc. What are some of the recommended practices for the following:
Code organization and structure, especially for apps rich in business logic?
How to handle logic that spans multiple models?
What are some good tutorials and sample code sites that demonstrate some good project and code structure with items (1 and (2 in mind?
.net comes with a lot of recommended approaches, practices, patterns and coding structure techniques that are actually very good recommendations. Sites like www.asp.net, etc. provide pretty good articles, etc. for these recommendations.
I am having trouble finding a consistent approach reviewing Node.js examples.
Like you I have come from C#/.NET to Node.js and found that much of what I thought was good practise in C# to be less than useful in Node.js.
Domain Driven Design (DDD) is not often discussed in a Node.js setting since DDD is usually associated with Object Oriented Design and Javascript is not an OO language (even though Javascript has prototype-based inheritance, a lot of OO patterns simply don't translate well to Javascript).
Instead we see more Microservice architectures whereby we break large domains down into smaller, decoupled services which perform one business function well. Node.js is perfect for these sorts of lightweight HTTP services.
The interesting thing I have found is that after trying a Microservices approach over DDD I actually find it much easier to implement and easier to keep things decoupled along appropriate lines. In fact when I go back to C# I find myself applying a Microservices approach there too.
In terms of patterns, abstracting away persistence is still an very good idea - something similar to the Repository Pattern translates well from OO to Node.js. As for where to put your business logic, I find I sometimes need a "Service" or "Application" layer over my repositories so I can reach into several repositories to compile a complex response. Sometimes you don't need that additional abstraction, so just put it where it's needed - don't get too religious about having layers for business logic - that's N-Tier thinking and it causes a lot of unnecessary code to be written. Add abstractions when they become useful, not as placeholders just in case they are needed - that's a kind of premature optimization.
When we need really high-level business logic, we may need to coordinate the actions of several Microservices. Node.js is your friend here too - you can write lightweight orchestration services that consume messages off an ESB and react to them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Now I don't have any specific question, rather a general, ask for opinions post.
Within a month we will receive the documentation of a project we have to develop. The website has a lot of potential and will be advertised in TV and radio as well when it'll be done. So it'll have a lot of visitors, members and it'll have a rich admin panel with lots of options. My friend who was asked to be the CTO is a senior PHP developer with almost 10 years of experience and I am a junior JS developer. (or less, I don't have years of experiences in JS, but I'm committed)
Is a JS MVC framework substitute for PHP? Is a PHP MVC framework substitute for JS? Are they both working well together or is it possible to not use any framework, but write the project in MVC approach?
For example:
model: PHP
controller: JS (jQuery+Ajax)
view: HTML, CSS
As my friend is a professional PHP developer and will have a daily job next to, but only in the beginning of this project, he doesn't really want to learn an other language (like Node.js), because almost everything is a routine for him now in PHP.
I know everything depends on the documentation and what we have to develop exactly, but I'm just a curious mind and want to understand more. I know I have much to make up and sometimes I worry of my current knowledge, but then I think that be whatever big the challenge, there will always be a solution for it.
MVC does not mean to use differenct languages for all of the modules (model, view, controller), but to loose couple and encapsulate certain parts of your application.
Against many opinions, MVC is not the panacea for application development. It really depends on the application you're developing.
It's not necessary to use any frameworks in order to follow the MVC approach. In fact it's a pattern that can be tied together very quickly, in it's most basic form.
If you decide to use your backend as an API and pull the data via frontend, you don't need to use MVC come hell or high water. For an API for example it's not necessary to perform most of the view tasks. Instead you should care about building a performant and scalable data storage layer (which for example is able to easily provide your data in many common formats, such as XML or JSON) and a strong router that can handle HTTP Requests nicely (See if REST is something for you).
In this case you want a strong frontend which can handle templates, and also has a strong layer for obtaining, sending and handling data in general. A strong controller layer that can delegate tasks to certain parts of your application would also come in handy.
Well you see what I'm talking about. It really depends on your application. In my example the backend wouldn't exactly follow the MVC approach, while my frontend would completely. MVC isn't about switching programming languages for certain parts of your application. Instead it decouples your application structure making things a lot easier.
Of course Frameworks come in handy when developing such an enterprise scale application, but it's not necessarily required.
To sum things up: MVC has not much to do with the code itself, it has much more to do with architecture and structure of your code. How exactely you're implementing it is absolutely up to you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
We are a student team maintaining a mobile app written mainly in javascript (also jquery) and PHP.
We recognized that we have to improve the structure of our code and have to implement structures and workflows within the Team.
Status of the code:
By now the code is still very tangled, not loosely coupled.
Classnames with identical names in different folders.
Wide usage of == instead of ===.
Wide usage of global variables.
We reinvented the wheel for parts of the code. (where frameworks already existed for certain purposes)
Status Methods/Tools:
We are now implementing SCRUM
We use Redmine Backlogs which works good for us.
We implemented a usable branching model for git. (http://nvie.com/posts/a-successful-git-branching-model/)
We started to use jsdoc to do an inline documentation of the code.
We stumbled across SonarQube (a code quality checking tool) and think this might be helpful.
We are still new to TDD and skeptic about it.
We do not have expertise in designpatterns but would like to apply them.
Only few in our team of round about 6 people know the basic concepts of MVC, MVV, MVP.
We want to start with refactoring our code (to unobtrusive js?) around the first week of september.
Which steps would you suggest so that we don't stumble too much and that the process is kept transparent and motivation is high?
Would you start by fixing little issues like the == / === thing? (things SonarQube comes up with)
Would you start with implementing a TDD framework but without having a testable MVC/MVV ?
Would you start with separating js from html and css?
Would you start with bugfixing of old, not yet resolved tickets to have absolutely clean branches?
Thank you very much for any suggestions/ideas/best practices
Marc
Well .. step nr.1: read this book. You have time enough for that till September.
Watch following lectures:
It Was Like That When I Got Here
Recognising smelly code
Unit testing
These materials should give you some sense of the subject.
As for real first steps, separating the HTML from JavaScript is a nice place to begin. If you know how to do event delegation in javascript - good. If not, look into it.
Then you can move on to fixing the part of page that spews out the HTML. Separate the SQL, add some abstraction, some OOP principles.
If you end up aiming at something MVC-shaped, then this list of links might help a bit.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I recently discovered Typescript. Coming from an OOP C# background, I find Javascript very difficult to work with and am naturally thrilled about Typescript.
I'm currently using Backbone.Marionette.js in my application to manage future complexity (future because it's still the early stage and not yet that complex).
Now I understand there is still room for Backbone.js to play an important role in my application even if I'm using Typescript, but the more I learn Typescript (and begin to love it), the more I start thinking that its objective in managing complexity in enterprise application overlaps too much with what Marionette tries to accomplish. I understand they do it in two completely different ways but coming from C# I of course prefer the OOP approach instead of yet another JS plugin.
Are my considerations to phase out Marionette out of my application justified or is there less overlap than I think? Keep in mind, I'm new to all 3 Backbone, TypeScript, and Marionette and this is the first application I've used them in, which makes it difficult for me to assess this question.
"TypeScript vs Marionette" is the wrong perspective. That would be like "C# vs WinForms", and asking "Should I stop using WinForms when I switch from C# to VB.NET?" This question doesn't make any sense because it is trying to compare a language to a framework.
There are some things that TypeScript will prevent you from doing with Marionette or any other JavaScript framework that takes advantage of JavaScript being dynamic. But that doesn't mean TypeScript replaces Marionette or any other framework. It only limits the usefulness of the framework due to restrictions that TypeScript places on you.
My answer would be based on the following considerations.
Firstly, what parts of Marionette are you using? If it is just the module loading then you don't need it. If you are using a lot of the templating and eventing it may be useful still. If you aren't sure yet what parts you might use, don't use it until you have a compelling reason to use it.
Secondly, how much can you write before you need to make decision? For example, if you start coding today, how long can you defer the decision. The longer you wait, the more information you'll have to help you make the right choice. If you write plain TypeScript, you can wait until you actually need to bring in a framework or toolkit and then choose the one that solves your real problem.
So really, my answer is start without it and wait until you have a problem to solve before choosing how you solve it.