I am coming from models and controller paradigm, where models deals with DB and controllers have the business logic to serve the REST api's.
Now, i am looking into a Loopback(framework based on Node JS) to do new project with it. But, it only have model to do all kind of stuff. I am not able to understand how i can merge service layer and controller layer into models. That sounds me a bit confusing.
If any one can provide the right direction for designing a system with Loopback. That would be very helpful.
When you create a new model, say Profile, you get 2 new files:
profile.js
profile.json
Consider profile.json as your model, actually just a declaration of your model. And consider profile.js as your controller. All RESTful APIs you need are dynamically generated by loopback, if you need to add additional logic to the regular APIs or create new ones, your starting point is profile.js.
Now, you can structure your application code as you like. I usually put all the application business logic into a service layer, having the module profile_service.js and referencing it from profile.js.
Related
While creating Backbone Models and Collections for a web page, I feel the data can be segregated as models and collections in multiple ways.
Consider an example where I have a web page and ideally I should create one backbone view and there by one backbone model for that view. However, the data has to go in to two different data base tables at server side. In these kind of situations, I get confused whether I should just consider the front end scenario while defining view/models or should I just create them based up on the server side POJO classes structure.
I mean, If I just think from front end perspective, I just need to create one backbone view and one model. However, if I think from server side Object's perspective, I need to create two backbone views and two models.
Could someone please tell me what are the things to be considered while dividing a page as different backbone views and models and kindly provide any references
This depends on your REST API.
Backbone does not directly interact with backend tables, it usually uses a REST API that interacts with the tables (or whatever data storage).
If the API has endpoints for performing CRUD operations directly on a table, then you should create a backbone model client side representing it, and use it's built in methods such as save(), destroy() etc to interact with the REST API.
If your rest API returns data which is the result of joins of multiple tables, has single end points that updates multiple tables on backend, then it makes sense to have a model containing data from all those tables, and interact with the REST API using built in methods which updates all these tables accordingly.
So in short, you should create the frontend models according to the REST API, not directly according to the database structure.
I'm writing a web crawler in Node. It will crawl my various bank accounts and provide me with a summary of my finances. Acknowledging the security issues around this, i'm just doing it as a proof of concept.
I'm having a problem with structuring my application.
So far my controller modules are:
/controllers/routes.js (contains express routes)
/controllers/configure.js (takes values from /settings.js and interprets them for /app.js)
/controllers/crawler.js (downloads a page, traverses DOM and outputs values from selectors)
/controllers/login.js (provides crawler.js with functions to log in to bank accounts)
Are these valid controller modules, or are they more suited for a directory such as /lib/?
At the end of the day it doesn't matter for the functionality of the project, but I'm presenting it at the end of the week.
Controllers are the things, which process requests by glueing models and views. The router routes a request to a controller, this one calls methods of models in order to render a view.
Since most of your code is just code to fulfill some specific tasks, which have nothing to do with the frontend code of your application: No, most of the code is nothing I would call controller code.
As you already said it makes more sense to group that into modules and put it in other directories. These functions are either called by the controllers, to render the frontend, or (more likely) are called via cronjobs to update the database.
I would like to use StrongLoop Loopback as a Node.js backend API for a backbone.js app.
Is there a way to define models attributes and methods (for example, for validation) that can be used both on the client side, in the backbone model, and on the server, in Loopback models definitions ? (Dont Repeat Yourself philosophy)
Loopback uses model definitions to initialize objects
Maybe I can extend Backbone.Model to be able to load the Loopback model definition syntax ?
Do you think it's a good idea / easy task ?
disclosure: I do front-end work for StrongLoop.
It is a good idea since the model definitions are stored as simple json. You can also use the API explorer output to pick up the url path properties as well.
We are just wrapping up a similar thing for AngularJS to auto-gen a model factory you can drop into your client modules and it's pretty slick so hopefully a Backbone version won't be too far behind.
I started reading some Backbone tutorials and I found one thing that astonishes me. Why models are created inside of view? What if I want two different views for one model (what I think MVC is for)? Let's say I need a model Colors, DisplayView view which displays them and ControlsView which allows me to set their configuration. How to handle this?
Backbone does not require that you create your models inside your views - you can (and often should) create your models independently of your views so that they can be shared. Also, just because you create a model inside a view doesn't mean you can't pass a reference to that model to another view and share it that way.
Most likely the tutorials you are reading are very simple and create single models for single views to make the tutorial easier to follow.
I'm currently building an application using Backbone.js with a number of different models that all relate to each other in various ways. I'm currently experimenting with various architectural approaches.
In a nutshell the model relationships looks something like this:
Workspace > Projects > Tasks
There are a few other models, such as lists and categories, that are attached to a project.
On a page with a task list, I'm dumping the JSON of the tasks onto the page and filling up the collection. This works ok, but at the moment all tasks are pulling in their own project data.
task.project.id
task.project.name
The projects are also being pulled in various other locations on the page for various lists. Tasks can also be part of a List which is assigned to a Project. This means I'm also making requests to pull in the lists for a project in various places as well.
The main problem with this is that when updating a model in place I need to find some way to 'sync' them. Which is crazy. They should all be using the same model instance so that each view is using the same model and is updated accordingly without having to do anything.
I've been researching various Backbone.js architectural designs to try and find the answer. Chaplin (https://github.com/moviepilot/chaplin), for example, uses a mediator object to pass data between views. Using this approach, I could have a Projects collection on the mediator and pass this around to the various views via the mediator object.
Each project would include all of it's lists, categories, assigned users etc. Then I could request for a project model like so:
App.Projects.get(12)
Then the task would just need the project ID and a getter and setter method. Views could get access to available projects, project lists, project users easily as well without relying on digging into the model or making further AJAX calls. Additionally, the task models wouldn't require any of the project data on them.
However, dumping all this data in a global object seems bad.
I would possibly end up with something like this:
App.Workspaces
App.Workspaces.get(1)
App.Projects
App.Projects.get(12).get('lists')[0]
App.Projects.get(12).get('users')
To use like this:
var projectId = model.get('project')
var project = App.Projects.get(projectId)
Or with a getter method:
var project = model.getProject()
And add the mediator as a dependency at the model level instead.
Adding a large global object like this adds a fairly large dependency that could make testing difficult. It also seems wrong to assume that the mediator will even have the project available. Maybe it could make the model, fetch it and return it if it doesn't exist.
Any help here would be great! I'd love to know how other people have solved this problem.
I recommend to have a common Collection for all your Task Models. Kind of cache.
Something like: App.Store.Tasks.
Any time you need to feed the Poject.Tasks look first in the App.Store.Tasks and then:
A. If you found the Task there then take it and add it to your Project.Tasks.
B. If not found there then create, fetch and add it to both: App.Store.Tasks and your Project.Tasks.
This way other Project that tries to fetch a Task that already exits will do the same and they both will share the same Model.
Any time you modify one of your Task models in a Project you'll be modifying this Task in every other Project.