I've been using BreezeJS in a number of projects for a while now, and I have to say that in most ways, it makes your life MUCH easier, which is why I keep coming back to it. However, I seem to consistently run into a scenario where it falls completely flat, and I cant seem to find any "correct" way of working around this issue.
Let me explain. One of the best things about BreezeJS is that it follow this UoW pattern that allows you to save entities using the saveChanges method of the entity manager, like EF.
However this is also a part of the problem, because as you develop more and more sophisticated application, I sometimes feel this approach is not always appropriate. I find that often I have:
Operations that doesn't really involve creating entities on the client, but rather involve executing an action on the web api that may result in the creation of various entities or other forms of state on the server, that should then be send back to the client.
Operations that involve entities with properties, that cannot be saved because some of them are private to the server, and should not be put on the client (often solved with a JsonIgnore for the client, but comes with issues when you start persisting the given entity again)
I feel that there is one thing that could solve these issues relatively easily, and it is a concept that already exists in OData: Actions. Actions that can be performed globally, on entity sets or on specific entities and then return either custom objects or entities that will be directly tracked by BreezeJS.
Currently, I find myself doing the following workaround (which I don't know if is appropriate):
Make a "Resource" action on the BreezeController that represents an action rather than an an actual resource. This takes in a custom parameter object and returns a non-entity object, that may contain actual entities (as described under "Cool Breezes" with the Lookups, because these will then be track by BreezeJS)
Use the "ajaxpost" breeze lab to allow querying a resource with a POST instead of a GET so any sort of arguments can be passed in.
Is there a more appropriate way of accomplishing something like this? Are there future plans to support custom actions?
An approach I have seen to solve this type of operation, is to simply make these sort of operations "around" the breeze api controller. That is, simply using an ApiController that has nothing to do with breeze. But I kinda feel this defeats the purpose of breeze, because then, if the operation results in the creation or deletion of entities, you must start tracking them by yourself on the client, by either creating them locally, or by issuing another breeze query to go get them. This really gets tiresome if you need a lot of these types of operations.
I’m struggling with the same issue myself. I have an app that uses breeze to store trades in a SQL database and after the trade is stored, another user can use the app to send the trade to a backend trading system. I created an OData action to do the import to the external trading system so I can do a post to /trades(123)/ImportTrade. When I get the metadata for the service using /$metadata it sees that the trades entity has this action (it's in the metadata).
I was hoping that breeze would see this in the metadata and create a method on the trades entity to do a post to my OData action, but it does not. This would be a great feature if it was added to breeze (exposing OData actions as methods on entities).
As a workaround I have extended the breeze entity myself with a custom method that does the post to /trades(???)/ImportTrade.
It would be great if breeze could handle this for us!
Your approach using ajax post is a good way to do thouse kind of things...
You can also make your own context by inheriting from BreezeContext that has nothing to do with a DB, and do your actions there with out saving the entites and still get the result back as a non tracked object or entities.
If you create a new entity on the server (not always a good idea with breeze, but still can still be done) you have to make sure that breeze will still generate the temp keys for that entity.
You can use the temp key generator or just delete the primary keys of the non tracked object.
You can use the metadata of that entity type in order to get it's primary key properties and then delete them using javascript like so: delete obj[prop]
then use createEntity with the non tracked entity that doesn't have primary keys.
Breeze will then generate the primary keys for you and your all set.
I also hope that Breeze will address the need to do custom actions that may return a custom non tracked object in a more intuitive way
Hope this helps
Related
I have an application with several Web API controllers and I now I have a requirement which is to be able to filter GET results by the object properties. I've been looking at using OData but I'm not sure if it's a good fit for a couple reasons:
The Web API controller does not have direct access to the DataContext, instead it gets data from our database through our "domain" layer so it has no visibility into our Entity Framework models.
Tying into the first item, the Web API deals with lightweight DTO model objects which are produced in the domain layer. This is effectively what hides the EF models. The issue here is I want these queries to be executed in our database but by the time the Web API method gets a collection from the domain layer all of the objects in the collection have been mapped to these DTO objects, so I don't see how the OData filter could possibly do it's job when the objects are once-removed from EF in this way.
This item may be the most important one: We don't really want to allow arbitrary querying against our Web API/Database. We just sort of want to leverage this OData library to avoid writing our own filters, and filter parsers/builders for every type of object that could be returned by one of our Web API endpoints.
Am I on the wrong track based on #3? If not, would we be able to use this OData library without significant refactoring to how our Web API and our EF interact?
I haven't had experience with OData, but from what I can see it's designed to be fed a Context and manages the interaction and returning of those models. I am definitely not a fan of returning Entities in any form to a client.
It's an ugly situation to be in, but when faced with this, my first course of action is to push back to the clients to justify their searching needs. The default request is almost always "Well, it would be nice to be able to search against everything." My answer to that is that I don't want to know what you want, I want to know what you need because I don't want to give you a loaded gun to shoot your own foot off with and then have you blame me because the system came grinding to a halt. Searching is a huge performance killer if it's too open-ended. It's hard to test for accuracy/relevance, and efficiently index for 100% of possible search cases when users only need 25% of those scenarios. If the client cannot tell you what searching they will need, and just want everything because they might need it, then they don't need it yet.
Personally I stick to specific search DTOs and translate those into the linq expressions.
If I was faced with a hard requirement to implement something like that, I would:
Try to push for these searches/reports to be done off a reporting replica that is synchronized with the live database. (To minimize the bleeding when some idiot managers fire up some wacky non-indexed search criteria so that it doesn't tie up the production DB where people are trying to do work.)
Create a new bounded DbContext specific for searching with separate entity definitions that only expose the minimum # of properties to represent search criteria and IDs.
Hook this bounded context into the API and OData. It will return "search results". When a user selects a search result, use the ID(s) against the API to load the applicable domain, or initiate an action, etc.
no. 1. is optional, a nice to have provided they can live with searches not "seeing" updated criteria until replicated. (I.e. a few seconds to minutes depending on replication strategy/size) Normally these searches are used for reporting-type queries so I'd push to keep these separate from the normal day-to-day searching options that users use. (I.e. an advanced search option or the like.)
I seem to have an unusual need that I need to be able to $expand objects, but I can not do that using standard IQUeryable.
I am using EntityFramework and AutoMapper to project from database entities to API data objects that I then expose via OData. This has the problem that it limits what I can do - to those elements that AutoMapper can ProjectTo.
This generally is not a problem - if the items in the Api object are part of the database. I now have certain objects where I must (sometimes optionally) add data that comes from other sources. We talk generally about data only held in memory (like an object's error details, which include the stack trace, or some runtime stats).
As such, I need to find a way to manipulate (filter) queries and - more important actually - to handle $expand in single entity GET operations (though support for multi get is also welcome, but there I can possibly handle this by using ODataQueryDetails).
For single item queries, though, I have a controller method in the form like:
Get ([FromODataUri] Guid key) {
which gives me no access to the ODataQueryDetails at all. Anyone knows how to get those query details in this case?
Documentation on the whole "customize the query" element is not particularly big - and generally seems to assume someone is "Just playing with some IQueryable interface" - not taking into account that you may need a multi stage processing or do something that mixes in memory and database data.
Note: Web API OData: How do you $expand on a single entity? is NOT a duplicate - that was a single issue with a parameter name (key required as name) and does not go deep enough.
If you simply add a parameter to Get as follows, Web API parameter binding will supply a value to the method. Let Thing be the entity type handled by the controller.
public IHttpActionResult Get([FromODataUri] Guid key, ODataQueryOptions<Thing> opts)
Note that you need to specify the generic version of ODataQueryOptions or you will get an exception.
This will get you an object representing the query options for the current request, but you will not be able to modify the options (none of the interesting properties have public setters). There seems to be a lot of developer demand for the ability to intercept and modify query options, but there is no out-of-the-box solution at the moment. See the open issue on Github that is currently targeting the 5.1.0 release. See OData V4 modify $filter on server side for current best practice on modifying query options in a controller method.
I still have difficulties with some NHibernate terms so please bear with me.
I am building a POCO class based off a web submission. The web user will be changing some scalar properties. The POCO will already be persisted in the database. I want to save changes to the POCO to the database, collect the child objects (which should be unchanged) and return the POCO's graph so I can send feedback back to the user.
What is the proper way to do this? Is this "detached"? What is the appropriate method for connecting the child collection? Can it be done in one database batch?
Persisting changes to your object is easily done using Session.Update().
retrieving child collection is done either implicitly (by accessing the collection property which causes nHibernate to fetch it from the DB), or explicitly, using the Fetch() method.
For example- var users = QueryOver<User>().Where(u => u.Age > 18).Fetch(u => u.Children).Eager.
In general, for a web app, I would recommend reading a little about the 'session per request' pattern. (this example is a little bit of an overkill for my taste, but it explains the concept quite well).
Also don't forget to always use transactions.
Our customer request the functionality of logging changes in db.
We need next structure:
"Timestamp", "User", "DB.Table.Field changed", "Value after change"
What we have:
Entity Framework Code First
ELMAH
MySQL Data Base with more than 100 tables (changes should be tracked to all of them)
So we need:
Somehow track what table was changed
What new value was added/updated
Generic functionality (if possible)
Any ideas how to do this?
PS. ELMAH is not a strict requirement. But MySql is :)
Thank you!
Ultimately, what you're looking for is some sort of behavior that keeps track of auditing. ELMAH is not geared towards that.
You most likely want to look in to some sort of Polymorphic object that can keep track of who executed what type of action on a known entity. You're most likely going to want to use some sort of AOP concepts. Libraries like like DynamicProxy2, LinFu should be helpful in this area.
Your goal would be to use proxy objects that wrap your existing entities and "inject" the auditing information that you need to track.
I actually had the same feature request and even though I wrote a tracking layer before for my generic repository I found that there is one available in Nuget/Github that handles this.
https://www.nuget.org/packages/TrackerEnabledDbContext/
https://github.com/bilal-fazlani/tracker-enabled-dbcontext
You can use this and I found that it works great for me. I use it into my Generic repository project.
I have a database with a lots of relationships between Tables and a Silverlight client that connects to my server with WCF service on ASP.Net side.
First i used LINQ to SQL as a robust mapper tables to object and in a WebMethod that returns a List<Foo> of my Database's object(suppose GetFoo()). The Foo has lots of relationships with other objects that each of that have lots of realaships too,(this means , there is a PK and FK between tables).also i use Microsoft Service Trace Viewr for track my service
When i call GetFoo() , WCF returns this error:
Object graph for type 'X.Y.Z' contains cycles and cannot be serialized if
reference tracking is disabled
I searched this error and find this great post but that is not working properly and i see same error too.
Various options:
remove the cyclic dependencies from your model; this might be tricky for a generated model that has lots of existing code built against it, but is worth a try; however, you typically want to not serialize the parent, which is exactly what LINQ-to-SQL wants you to keep (it'll let you drop the children property, but that is what you usually want to serialize)
enable cyclic references; it looks like you've tried this without success; did you enable it at both ends, though? Actually I wouldn't be surprised if Silverlight doesn't like this extension (it has limited extension support)
use a separate (flat) DTO model for data transfer purposes
try using NetDataContractSerializer; I can't remember if this is supported in Silverlight, and I must admit I'm not its biggest fan, but it might be a pragmatic fix here
I'd vote firmly in the "DTO model" category; simply, having a separate model means you are less likely to run into tangles whenever you tweak the DB - and you are in complete control over it.
A bit late this. But if anyone are using linqtosql and have this problem you can simply just open the tables in your dbml class. Right click next to a table and click properties.
HEre there is a property named Serialization Mode.. Set it to Unidirectional
The error will be gone
I know this is an old question now, but did you try decorating the classes generated by your DBML with [DataContract(IsReference=True)]?
I had the same problem in 2010 and had to resort to some fairly extreme measures to get it to work on client and service sides, but recently went back through it with VS2013/.NET 4.5 and had much less pain, as documented here (with EF v6 RC 1 POCO objects): http://sanderstechnology.com/2013/more-with-the-entity-framework-v6-rc1/12423/