I have recently gone thru several articles on AngularJS. As AngularJS maintains controllers and models separately from view. As soon as model gets updated it updates View automatically and vice versa as it is two way binding. But as much I have gone thru all the articles I have found that all views, models and controllers are managed on client side.
Do we have any way to put controllers and models on different machines than client side ?
Yes, but not automatically. AngularJS is a client-side MV* framework. There are also server-side frameworks and even some combos like Meteor that run on both sides. But always there is some messaging back and forth, and at the end of the day, what is it you wish to do on the server? Servers and clients are almost always very different, and where a client might be drawing forms and tables, a server might be reading/writing database queries or managing multimedia assets. That means there's rarely a benefit to a 1:1 duplication of functionality in both environments.
I would suggest you evaluate the excellent ExpressJS framework for NodeJS. This is a great building block for server-side MV* apps, especially when combined with a good templating library like Swig. You can easily create a CRUD API here (in just a few minutes) that manages creating/updating data objects in a model and storing them in a database like MySQL, Mongo, or something like Redis. Then, back in AngularJS, you can use $resource, Restangular, or similar to map between the two.
This technique has a few more steps in it than Meteor would, but it gives you an incredible amount of flexibility and doesn't take very much code to produce.
Related
I plan to use AngularJS verion 1.latest. I'm new to this framework. Previously I was programming in mainly in PHP. I've studied https://docs.angularjs.org/tutorial
As far as I understood - there is no model stricte. Controller has $scope and this is the data layer for view.
Then I have troubles how to logically put data models into Angular application. Assume that data model represents computer: 1 mainboard with some properties, 1..* ram modules, 1..* processors, 1..* hard drives. Each device has its own properties. The data is fetched via RESTful API with several requests.
The data will be shared among few controllers.
How should all this be organized to preserve testability? I'd use Service for operations with REST.
I was talking to very experienced developer. He confirmed what I've studied by myself.
For storing data about PC I use a service (lets call it data-service). Data can be fetched by the same service or another one. Then data from data-service can be accessed in each controller and assigned to controller variables available in view (which should use controllerAs).
The guy also suggested to have as small data models as possible. It should be pure objects (can be nested) preferable without additional methods (opposite to classes from any backend) as they role is only to carry data. This sounds like truth in 90% of cases.
We're getting started on a new application that will run on several platforms (web, mobile, tablets etc). The goal is keep the models and controllers the same for all the platforms. Only the views will be changing. For example, if I have Roles view (and RolesCtrl) and Persons view (and PersonCtrl) on different pages (roles view redirects to persons page with role id as query string or something) on one platform, these two views might be combined into a single page (role id should not transfer to person page but to another view on the same page) on a different platform. I understand I can have separate divs and keeping the controllers intact, but since the UI flow is different for different platforms, how can that be handled? Is it feasible to keep the controllers unchanged?
Is this the right approach? Any help is greatly appreciated.
I would suggest proving this out by creating a small project to implement some piece of functionality backed by a service that AngularJS will communicate with.
It sounds like you might have some behind the scenes complications here. I would suggest that if you do use AngularJS to make sure all of the developers are making their HTTP communications done through AngularJS and not try to go work around it.
From my short experience with AngularJS I think it would work fine and may actually make things simpler because of it's easy single application model.
I am Java programmer who tries to investigate CakePHP - currently I have problem with application structure/design. I could not understand where to put core logic of application.
When I am developing in JavaEE, common approach looks like following:
Model classes are simple beans which represent data entities (products, people etc) - mostly like data structures with getters/setters;
Controller classes are simple enough classes which aggregate necessary data and inject them into dedicated View template which is then sent to user;
DAO (DataAccessObject) or Repository classes are ones which can load and store entities into database;
Service classes are usually singletons which contains certain business-logic methods - these are called by controllers, by other services or by scheduled actions, on the other hand they themselves call DAO / Repository methods to fetch or modify data.
For example if I have entities Person, Product and Order, when user selects some product and clicks "put it into my cart/basket" new Order for this Person should be created and this Product should be added to this Order (we may check that Person is not bad debtor and that Product is present at store etc.) - all this work is performed in methods of OrderService called by some controller.
Usually some kind of IOC (Inversion of Control) is used so that all services and controllers have links to necessary services etc.
Now I am slightly bewildered about how this all is done in CakePHP. Where should I put this business-logic etc. ?
In CakePHP the model layer is made up from collection of active record instances, called AppModel. They combine the storage-related logic (that you would usually put in DAOs and/or Repositories) with business logic (what usually went into your "models").
Any other domain related logic (from your Service) becomes part of controller.
If you want to know, how you are supposed to implement domain business logic in CakePHP, just look up articles which praise active record pattern.
Personal opinion
CakePHP and CodeIgniter are two of the worst frameworks in PHP. They are filled with bad practices.
Actually, if you were doing correct-ish MVC, then model layer would contain all of the business logic and everything that is related to it. Model layer is made of DAOs, Repositories, Domain Objects (what you call "models") and Services.
While your descriptions of Java-based code indicates, that you are kinda moving in that direction, CakePHP is not even remotely close to it.
Then again, it might be that my understanding of MVC is just wrong.
The controllers should only contain logic relevant for the whole thing being a web application. Your business logic belongs into the models. I think it is one of the basic mistakes that you find in many cakePHP applications, that to much logic is put into the controllers, which actually belongs into the models.
In CakePHP. the "M" is just a bunch of Data Models instead of Domain Models.
In my opinion. CakePHP is made for RAD development. It is not a good fit for enterprise applications.
My opinion though.
am new to learning about MVC.
I am wondering if there is a heuristic (non programatically speaking) out there for dividing and deciding what logic goes on the front-end as opposed to the back-end especially when using front-end libraries like backbone.js.
That is, libraries like backbone.js separate data from DOM elements which makes it useful for creating sophisticated client side logic that, perhaps, used to be carried out on the server side.
Thanks in advance
Joey
The "classic" way to do Model - View - Controller is to have all three on the server. The View layer output of HTML and some JS is then rendered by the browser.
Rails is an excellent example of this.
The "new cool" way is to treat the browser as the main computing engine with the backend server providing services via APIs.
In this case, the Model, View and Controller software all run (as Javascript or coffeescript) on the client. Backbone is often a part of the browser-side solution but it has alternatives such as spine, angularJS and others.
On the backend server, you run the dbms and a good API system. There are some good frameworks being built on Ruby/Rack. See posts by Daniel Doubrovkine on code.dblock.org You have many choices here.
Advantages of MVC on the client
Responsive user interface for the user
Cool Ajaxy single page effects
Single page webapps can provide much faster UI to user than regular web sites
Good architecture, enabler for purpose build iPhone/Android apps
Depending on the app, can be used to create standalone webapps which work without a network connection.
This is what many cool kids are doing these days
Disadvantages
Need to decide on approach for old browsers, IE, etc
Making content available for search engines can be tricky. May require shadow website just for the search engines
Testing can be a challenge. But see new libs such as AngularJS which include a testability focus
This approach involves more software: takes longer to write and test.
Choosing
It's up to you. Decision depends on your timeframe, resources, experience, needs, etc etc. There is no need to use backbone or similar. Doing so is a tradeoff (see above). It will always be faster/easier not to use it but doing without it (or similar) may not accomplish your goals.
You can build a great MVC app out of just Rails, or PHP with add-on libs or other MVC solutions.
I think you're using the word heuristic in a non-programmatic sense correct? I.e. you're using it to mean something along the lines of 'rule of thumb'?
As a rule of thumb:
You want the server to render the initial page load for UX and SEO reasons.
You could also have subsequent AJAX partial page loads rendered by the server for the same reasons. Profile to see which is faster: having the server render and transfer extra data (the markup) over-the-wire vs. sending a more concise payload (with JSON) and having the client render it. There are tradeoffs especially if you take into consideration mobile devices where maybe rendering on the client will be slower, but then again there are mobile devices out there with slower internet connections...
Like any client-server architecture: You want the client to do things that require fast responsiveness on the client and then send some asynchronous operation to the server that performs performs the same task.
The take away is vague, but true: it's all about tradeoffs and you have to decide what your products needs are.
The first two things to come to mind for me were security & search..
You will always want to restrict read/write access on the server.
in most instances you will want to have your search functionality as close to the data as possible.
I've created unmaintainable websites using PHP because it was so easy to do things quick and dirty. I don't want to do the same thing with Python/Django on Google's appengine.
Is there any good architecture references for creating websites using Django and appengine? (E.g. where to put business logic, where to put data access logic, how to cleanly separate the views, how to do unit testing, etc.)
Django by its nature will make it harder to put things in the wrong places. That is one of the cool things about the new generation of MVC frameworks, you have to work at it to create a ball of mud.
If you decide to not use Django, these hints from Werkzeug team might be interesting. This application structure takes what's best from Django but gives you complete freedom over actual layout (no need to have models.py even if you do not have any model in application...).
As already mentioned, by choosing Django, you have already taken a big step in avoiding spaghetti. Django provides you with an MVC framework (Model Template View to be Django specific). Thus, your job now is to study and properly follow the MVC design pattern which Django is guiding you with. Where you place your business logic will depend on your specific application and requirements. In some cases, some business logic is placed closer to the data in the models, and in other times its placed in the controller. Furthermore, GAE doesn't require Django and in some cases GAE's webapp framework should suffice.