CODEWITHSUNDEEP
asp.net-web-apiodatabreeze
ridermansb
ridermansb

Reputation: 11059

Working with Breeze + ViewModels

In my app I have my domain layer and web interface (other layers I will not go into details).

My views, working with ViewModels objects, and the database persist domain objects.
To convert a ViewModel object to a domain object I use AutoMapper.

The problem with the working Breeze is that when I will create a new object var newCust = manager.createEntity('Customer', {name:'Beta'}) this is a domain object, and should be an ViewModel object.

Not all, but in some cases the ViewModel is not similar to the object domain. For example, collections of objects in the domain are: ICollection<Person> while in view model are ICollection<int> int is a PK of person.

Question

How to working with breeze in these cases?
How to make the metadata also manages the structure of my viewmodels so I can create objects of type my ViewModel?

Upvotes: 1

Views: 978

Answers (1)

Ward
Ward

Reputation: 17863

@ridermansb - Because you mentioned AutoMapper, I will assume that your mapping is taking place on the server. You want your server API to expose "ViewModels" (in this case you might call them DTOs) rather than the domain model objects. Sometimes your ViewModels mirror your domain objects exactly; sometimes they don't.

Your client only sees what your API exposes. If this is a BreezeJS client, you will likely treat the ViewModels as client-side entities. They are Breeze entities in the sense that you expect Breeze to query, cache, change-track, and validate them. BreezeJS doesn't know whether these "entities" correspond to server-side DTOs or server-side business objects.

Of course if you're using DTOs/ViewModels, your server code is responsible for translating between the DTO form and the domain object form. Presumably this logic lies somewhere in/between the server-side API layer and the domain layer.

If you have chosen this architecture, you have chosen to deal with the bi-directional translation between ViewModels and domain objects and have embraced all the complexity and hassle that entails. I have no words of advice for you on that score.

So let me rephrase and narrow your question: "How can I get metadata that describe the object model exposed by my server-side API?"

My favorite way (assuming a .NET server) is to let EF do it for me. I create a DbContext that references NOT my domain model classes but rather my ViewModel/DTO classes. Of course these classes would not actually map to a real database. No problem; they don't have to. You will never use this DbContext to access data. You will only use it to generate metadata. You are using EF as a design-time, metadata-generating tool ... and that's it. This is an efficient maintainable approach.

I hope to demonstrate this technique "soon" but I've been mighty busy recently so no promises.

Alternatively, you can write the metadata by hand as described here.

Upvotes: 1

Related Questions