We are working on an SPA which uses Durandal + Breeze, we have used DTOs for data transfer, is there a way in Breeze through which we can make some of the properties of objects as Observable while keeping the rest as plain Javascript properties.
Please help.
Not easily, but depending on your willingness to look at the breeze source, you could take a look at the JsonResultsAdapter and the "ko" (knockout) model library implementation. Together these two control how entities and projections get materialized.
Related
I've built my WebAPI to serve DTOs to the client as a means of separating the domain models from the client-side models. I'm now ramping on client-side technologies like Breeze and I'm wondering how using Breeze would affect this pattern, and if it's an either/or kind of scenario. When is it a good idea to use both breeze and DTOs, if ever?
Breeze doesn't really care whether you want to use a DTO or a more full fledged domain model 'Entity' object. From a .NET perspective, Breeze can apply its full range of query services to any collection that can be exposed as an IEnumerable or an IQueryable. If you don't want to use queries, you can expose individual DTO's or collections of DTO's via WebApi methods that take parameters.
You also have the option of using Breeze queries with projections to construct DTO objects from entities on the server and only work with the DTO's on the client.
If querying is important to you, then the primary issue with DTO's vs domain model 'Entities' from your perspective is how easy it is for you to expose your DTO's as 'Queryable' objects and how efficient this querying is likely to be. Many ORM tools, like Entity Framework, are able to transform a query so that most of the heavy processing is performed by the Database engine. Such optimizations can be very performant in comparison to the alternative of trying to iterate over a DTO collection in order to execute a query.
One interesting alternative is to use something like the Entity Framework and WebApi to expose only the mapped subset of your domain model that you want exposed on the client. i.e. you use the Entity Framework to do your DTO mapping for you. So you have two EF models, a full domain model and a DTO domain model. The advantage of this, is that you still get the advantage of query optimization.
Hope this helps.
Is it possible for Breeze to access a third party API that does not have a "BreezeController" nor supports OData?
"BreezeController" is simply a .NET attribute that helps .NET WebApi provide support for query filtering and ordering via OData "syntax" and well as json serialization support for entity graphs and type identity. Type identity is important so that breeze can track the entities within its entityManager and merge the results of queries and update relation properties. OData itself is never required.
If you don't want the ability for the client to add filtering and ordering instructions to the server, you can write your own attribute that simply provides the json serialization support. The json serialization consists simply of configuring the json.net formatter that web api is already using.
The source for the BreezeControllerAttribute may be found in the Breeze.WebApi project and is really pretty short. Just create your own 'FooControllerAttribute' by copying the 'BreezeControllerAttribute' and remove the IFilterProvider code.
On the other hand, the query and filtering support won't hurt anything and this logic isn't even applied unless you use the EntityQuery 'where' 'orderBy' 'select' or 'expand' methods, so unless you want to explicitly remove this ability there is no need to not use the 'breezeControllerAttribute'
I'm very new with breezejs and having a few questions.
I think that breezejs has very nice features so I can replace my own datacontext. However, I don't want breezejs to interact directly with the dbcontext layer. In fact, in my application, the Service layer only exposes ViewModels - not even the real Business models - to the Controllers . So i'm not so sure whether I can use Breeze or not, since in few Breeze's examples, I only saw Breeze interact directly with DBContext.
Thanks.
=========================================
Thanks Ward for the answer,
About the features that I like from Breeze is that it will help to reduce a lot of time to build my own client-side view models. And to build a SPA, maintaining client-side view models is really painful for me, especially my application have desktop app client and other hand-held device's apps as well. Also, to handle the mapping from a JSon object to Knockout - which means with each view models, I will need a mapper as well.
Currently, my architecture is like this:
Server-side:
Repository layer <=> Service layer <=> Controllers (with the Web API that exposes to Client-side)
Controllers only can get the data (in format of a View Model) by sending request through Service.
So, my question is whether it is possible to make use of Breeze to query and also its integration with knockout.
Breeze never works directly with your DbContext; it works with the service model that you expose through endpoints on your service (e.g., Web API controller methods). But you certainly get the most value from Breeze when the client can query and save entities that are structurally the same as entities on the server.
You can retrieve ViewModels with Breeze - you can call almost any HTTP service method with Breeze. It's not clear to me how Breeze would help you manage those ViewModels on the client once you had retrieved them.
What features of Breeze seem "very nice" to you? Your answer to that question will help you determine if Breeze can be helpful with your preferred architectural style.
Querying data through Breeze without API controllers using DBContext directly should be no problem, saving might be harder but still manageable. I think the most complicated part is to get metadata to the client.
According to this SO answer, samples for exposing metadata from other sources that DBContext directly should be out in a week or so.
Meanwhile, check BreezeJS spa-template sample as there is repository pattern involved on the server side which makes it similar to your data access setup.
I wanted to know which would be best suitable - EDM or reflection provider for a project.
Definitely EDM is much simpler to develop over the database.But the problem is that,if we already have a data access layer over the database then we may have to change the existing architecture if chosen with EDM.So i wanted to know if there were any specific differences in using between entity data model or reflection provider to expose the data as Odata feed.
Reflection provider uses reflection to build model based on your class hierarchy. EDM provider uses directly the model created by the Entity Framework. If you have already a data access layer then I think you actually have three options:
- try using Reflection provider if it works great. Unfortunately I doubt it will work - it will change your objects but I don't think it will send queries to the database. In addition to be able to update data you will need to implement IUpdatable interface
- with EDM/EF provider you would probably need to move all you data access layer to EF. This means you would probably have to get rid of the access layer you have. The benefit is that once done it should work pretty much out of the box (queries updated etc)
- finally you can implement a custom provider. There is a few interfaces you would have to implement which would act as a bridge between the WCF Data Service and your access layer. Note that it is quite a lot of work. Here is the first post in the series that describes how to do it: http://blogs.msdn.com/b/alexj/archive/2010/01/07/data-service-providers-getting-started.aspx
I am confused as to the limitations of what gets defined in the Repositories and what to leave to the Services. Should the repository only create simple entities matching tables from the database or can it create complex custom object with combinations of those entities?
in other words: Should Services be making various Linq to SQL queries on the Repository? Or should all the queries be predefined in the Repository and the business logic simply decide which method to call?
You've actually raised a question here that's currently generating a lot of discussion in the developer community - see the follow-up comments to Should my repository expose IQueryable?
The repository can - and should - create complex combination objects containing multiple associated entities. In domain-driven design, these are called aggregates - collections of associated objects organized into some cohesive structure. Your code doesn't have to call GetCustomer(), GetOrdersForCustomer(), GetInvoicesForCustomer() separately - you just call myCustomerRepository.Load(customerId), and you get back a deep customer object with those properties already instantiated. I should also add that if you're returning individual objects based on specific database tables, then that's a perfectly valid approach, but it's not really a repository per sé - it's just a data-access layer.
On one hand, there is a compelling argument that Linq-to-SQL objects, with their 'smart' properties and their deferred execution (i.e. not loading Customer.Orders until you actually use it) are a completely valid implementation of the repository pattern, because you're not actually running database code, you're running LINQ statements (which are then translated into DB code by the underlying LINQ provider)
On the other hand, as Matt Briggs' post points out, L2S is fairly tightly coupled to your database structure (one class per table) and has limitations (no many-many mappings, for example) - and you may be better off using L2S for data access within your repository, but then map the L2S objects onto your own domain model objects and return those.
A repository should be the only piece of your application that knows anything about your data access technology. So it should not be returning objects generated by L2S at all, but map those properties to model objects of your own.
If you are using this sort of pattern, you may want to re think L2S. It generates up a data access layer for you, but doesn't really handle impedance mismatch, you have to do that manually. If you look at something like NHibernate, that mapping is done in a more robust fashion. L2S is more for a 2 tier application, where you want a quick and dirty DAL that you can extend on easily.
If you're using LINQ then my belief is that the repository should be a container for your LINQ syntax. This gives you a level of abstraction of the database access routines from your model object interfacing. As Dylan mentions above there are other views on the matter, some people like to return the IQueryable so they can continue to query the database at a later point after the repository. There is nothing wrong with either of these approaches, as long as you're clear in your standards for your application. There is more informaiton on the best practices I use for LINQ repositories here.