How to implement BREEZE.JS Partials that are more than Partials?

Question

I'm using the CodeCamper Pluralsight example by John Papa as a base (Durandal framework, which is a great project to get started with).
I have a customer entity and would like to display a list of customers that are analogous to partials, where you just retrieve part of the data for the entities. The difference is that I would like to retrieve/display additional fields that are not part of the customer entity. Examples: 1) Total Sales for the year 2) Date of the customer's last order.

I would like to extend the definition of "customer" on the client and store this data there. That way if I go to the customer detail, update the customer name for example, the change will be reflected when I go back to the customer list, since the data will be retrieved from local cache.

But I also have to make sure that when I save changes, those extended properties (total sales and last order date) do not cause problems since they do not exist in the customer model.

Is this possible? I know a little about DTO's, is that the way to go? Can I add properties dynamically that aren't referenced in the metadata, or will that cause me issues?

Thanks

What you are referring to are unmapped properties. If you want to have unmapped properties see the docs here - http://www.breezejs.com/documentation/extending-entities - or here - http://stackoverflow.com/questions/16524073/handling-calculated-properties-with-breezejs-and-web-api — PW Kad, Oct 14 '13 at 22:56

score 0 · Answer 1 · answered Oct 16 '13 at 15:09

I had a similar issue recently and I improvised a bit.

If it would be to follow your example, I first retrieved all the customers and stored them into an observableArray(), called customers.

Afterwards, I wrote a function that takes as a parameter the customer object, and creates some other more proprieties dependant on the customer object. Because "my customer" had some foreign keys as attributes, I needed this behaviour to solve the foreign keys. I though the easiest way to accomplish it would be using ko.computed. The coumputed could sove the foreign key based on the customer attributes.

My function looks something like this:

function ExtendedCustomer(customerValue) {
    var self = {};
    self.customer = customerValue;
    self.department= ko.computed(function() {
        read: function(){
            return getString(self.customer.Department()).StringValue();
        },
        write: function(newValue){
            var newString = createString(newValue);
            self.customer.Department(newString.StringID());
        }
    });
    self.description= ko.computed(function() {
        read: function(){
            return getString(self.customer.Description()).StringValue();
        },
        write: function(newValue){
            var newString = createString(newValue);
            self.customer.Description(newString.StringID());
        }
    });
    ...
    return self;
}

This function would return an object that contains the customer + some other proprieties. I called this function for all the customers retrieved and then store them into a different observableArray():

var helper = ko.observableArray()
for (var i = 0; i < customers().length; i++) {
            helper.push(ExtendedCustomer(customers()[i]));
}

Then instead of binding to the original customer I was binding to the extended ones.

The computed offered me the functionality to create some more proprieties based on the customer entity and then modify the customer entity if one of this added proprieties has been changed.(Read how can you use a computed to read and write values.)

I chose to do this because I only needed these extended objects in one of mine viewmodels. If you need them in more than one viewmodels you could scope this extended objects in an upper level so it would be common to your viewmodels.

If you need to scope it to more than one viewmodel you could also follow the example in John Papa's course and add proprieties to the customer entity by mapping the DTO's to entities. This way it would be easier for you if you want to access it in different vm's. The only down would be if you need to add a lot of properties(or solve foreign keys) you would have a lot of functionality on the dataservice if you follow John Papa's example. You should move it into a mediator object.

How to implement BREEZE.JS Partials that are more than Partials?

1 Answers1