9

First of all I must admit I am quite new to Angular.js and I haven't used any new generation js framework like Backbone or Knockout before. I'm creating an application which communicates with server using RESTful API. I dug a lot into angular documentation and blog notes so as I could do it right.

I found examples mostly with $resource. It looks pretty good: many built-in methods, when you design your REST interface properly you don't even have to write anything more.

But I (and my whole team too) are more used to JavaEE way of thinking about model layer: lightweight model classes (POJO, etc), DAO classes persisting and fetching model and optionally service layer between DAO and controllers. On the other hand in Angular $resource creates something more resembling active record.

I've already come up with two ways how to implement DAO pattern in Angular:

  1. Writing everything from scratch, going down to the $http abstraction level. I'd implement every DAO method as $http call, take care about errors.
  2. Using $resource objects normally like lightweight model classes and passing them to DAOs which are the only unit responsible for calling actions like .$save() on them. Of course we cannot prevent calling it in different place, but solution with such convention is good enough for me.

Second way looks better for me because of reusing existing code. $resource has nice behaviour of promise object and I will be happy if I don't have to implement it myself.

So finally the main question: is active record approach is the only way of doing data access right in Angular, Backbone and other tools like that? Maybe somebody have already tried to incorporate similar solution more resembling DAO in his code and can share his thoughts about it?

And the second question: is $resource object sufficient when it comes to dealing with errors, connection losses and different problems? Is it worth to use $resource having this in mind or it's better to start with lower level $http.

I am at the beginning of the project and I know that this decision may well affect the whole project life later, so I want to choose the best.

Mequrel
  • 727
  • 6
  • 12

1 Answers1

2

I totally agree. Here is the way I do it:

bankApp.factory("CustomerRepository", function ($resource) {
    var customerRepository = $resource("rest/customers/:id", {id:'@id'}, {'update': {method:'PUT'}});
    // You can also add addition repository like $http calls onto the
    // customerRepository like getting the count and other stuff.
    return customerRepository;
});

Then you can inject the CustomerRepository where ever you need it. For example:

bankApp.controller("BankController", function ($scope, CustomerRepository) {

    $scope.customers = CustomerRepository.query();

    $scope.createCustomer = function () {
        CustomerRepository.save($scope.customer, function (customer) {
            ...
        });
    };

    ...

    $scope.saveCustomer = function () {
        CustomerRepository.update($scope.customer, function (customer) {
            ...
        });
    };
});
testing123
  • 11,367
  • 10
  • 47
  • 61
  • 2
    Not that you actually gained something here. You've just exposed resource renamed as 'repository', with the 'update' method added. You still don't have rich domain model objects, nor any benefit over having called customer.$save() / customer.$update() – zappan Jan 24 '14 at 12:41
  • @zappan Perhaps I am missing something, what is gained is the fact that you don't have to repeat '$resource("rest/customers/:id", {id:'@id'}, {'update': {method:'PUT'}});' everywhere you want to do something with that resource. Change the name from CustomerRepository to CustomerResource if you like, the point is to keep the creation of the $resource in one place. – testing123 Jan 24 '14 at 22:50
  • 2
    You're missing that this is not a DAO pattern, which implies a separation of concerns between the model (rich domain model, if you wish) and a DAO (data access object) which takes care of persistent storage for the model. The original question was about DAO pattern, which is not what $resource is all about. – zappan Jan 31 '14 at 15:36
  • What I am saying is that by wrapping the $resource in an Angular service and treating it like a repository you can have some of the advantages that come with the DAO pattern. Think of restful calls to the server where you are doing GETs, POSTs, PUTs, and DELETEs on a resource. Similar to CRUD operations that you would do server side. Then you can treat you js objects as your rich domain model instead of doing rest calls from the js objects (eg myDAO.get instead of myObj.get()). – testing123 Feb 01 '14 at 06:24