Does Breeze elminate the need for DTOs in single-page-applications?

Question

I'm building my first SPA and I've gone as far as building DTOs for each of my entities, but I just found breeze and it seems like it takes care of serializing your changes into bare-minimum packages to optimize updates/additions/etc.

The reason I built DTOs is to "flatten" my data and limit how much data I'm putting on the wire, but I'm wondering if I even need this overhead if Breeze takes care of it.

Answer 1

There are reasons for DTOs. "Flattening the data" is not one of them. Neither is "limiting how much data I'm putting on the wire".

Breeze does a nice job with object graphs. Imagine sending 100 orders for a customer. You wouldn't want to repeat the customer name on each order DTO. With Breeze you query for the Customer orders (use an "expand") and you get one copy of the Customer and the orders to go with it.

var query = new breeze.EntityQuery.from('Customers')
           .where('Id', 'eq', 42)
           .expand('orders');

On the other hand, if you only want a list of customer names, use a "projection":

var query = new breeze.EntityQuery.from('Customers') // all customers
           .select('id, companyName'); // project into an anonymous 2-property object

Use the occasional server-side DTO to build something that you can't easily create from the client (e.g., Customer-and-total-current-year-order-dollars).

The point is that you can mix DTOs, projections, and entity queries to suit your needs. You do not have to go all one way or the other (in my opinion).

Answer 2

We are currently evaluating a change from Knockout to Angular and Breeze, to get rid of much of the DTO and DTO-Mapping Code that we wrote (server and client side code). What we have done was to not expose the DAOs but to create DTOs for all entities. What happend in the end is, that we had in many cases (not all) classes that looked 90% similar to the database objects. This led us to the conlusion that DTOs in our case dont make sense and the overhead we took was wasted effort and we need to get rid of this with a better approach. So a refactoring round has to start :-)

Since here we have the two experts (@John and @Ward) in one place, I would also take the chance to answer the question and furthermore raise one concerning the implementation, which I haven't fully answered for myself so far and maybe John and Ward can clarify this, since I think this is am important side aspect of the question if DTOs are still needed.

Looking at breeze it seems to be of great help to avoid a lot of DTO and DTO-Mapping code and I completly agree that usage of DTOs for getting less over the wire together with breeze makes no sense, because that is something that is handled perfectly by breeze as explained above with the query on client side. This is something I can completely confirm and makes sense. Also creating many different DTO classes as we did is not the best approach. Breeze does this much better with much less code.

To use DTO and DTO mapping code for separation of concerns I still believe is a good idea and principle, but it comes with also a lot of overhead that is probably in many cases not needed. So to take advantage of breeze, you can of course create DTOs and write/generate metadata on client side, but that is not basic idea of breeze. You can use it this way, but the more you stay on DAOs, the less code you will have to write and the faster your project. But nevertheless breeze allows you this so the framwork will also work with DTOs, its just not the basic idea why breeze was written. A mix of both (exposure of DAOs and DTOs) is probably the best approach.

But when then use DTOs ?

• Security
• Complex Logic (calculation) or when you aren't able to use simple CRUD methods because of too much complexity that you dont won't or cannot (security) expose on client side.

In case of security I am actually not 100% sure and this is why I am writing here and would like to ask the two experts. We are using EF on server side and what would be probably the best idea is to use projections on server side for security. But how to do that ?

I raise this question because I think its the most important to answer for being able of answering the question if DTOs are still needed.

We ended with the following code for EF (in our evaluation demo):

private IQueryable<News> RestrictFields(IQueryable<News> query)
    {
        return query
            .ToList() // This seemd to be needed, otherwhise I cannot use new News()
            .Select(t => new News()
                {
                    Id = t.Id,
                    Text = t.Text,
                    Title = t.Title,
                    Date = t.Date
                })
            .AsQueryable();
    }

So as you can see above, we have an EF query. So the first we tried was just to to a projection with new News(). That did not work, since EF does not allow you to use the same DAO class in a projection, just DTO objects or anonymous ones. So we used the workaround of ToList() and then AsQueryable(). But this does not seem right and furthermore probably then the query parameters from the client dont get shipped to the database and probably some wont work because of this, like "expand".

So what is the best way to do a projection on server side for security reason, so to finally get really rid of the need for DTOs ? @John: I saw a post of you where you say, you used projections on Speakers in your demo project for your training class (Angular and Breeze), but I cound not find where this is implemented.

Here I am really stuck and this is for me the missing link to know if DTOs are still needed or not, and how it then can work perfectly together with Breeze.

I hope my answer helps answering a little bit your question and furthermore I hope it provides also you Jake with some very important link in the usage of breeze and if DTOs are still necessary.

Kind regards,

Chris