Sounds daft i know but i want to do something a bit out of the ordinary ...
essentially I'm looking to build solution that has a wcf data service at the back end (or something of that ilk at least) that allows me to query my database using simple url syntax.
the problem i have is that when my db schema changes i have to recomile the entire back end and that's not good because the solution i'm building allows the definition of "entities" so to speak.
Essentially what i want to do is have the model update every time the db updates ... as a sort of triggered event.
I'm thinking that EF won't do this which leads me to my actual question ...
How would you solve this problem?
I need exactly what a wcf data service offers out of the box ... just with a more dynamic data model beneath it.
You need to change the O/RM to something more dynamic ... something like Massive could be used instead of EF.
Someone looks to be doing similar with WebWCF ... Massive with WCF Web Api to return dynamic types/Expandos?.
If you use data services then you'd need to figure out some way to represent the Massive as a 'DataContext'. WebWCF on the other hand would serialise dynamic objects as a lump of JSON or XML where required.
The problem with your proposed approach is one where the Web Service contract is dynamic and not versioned. This means that if you delete/rename/change a field you essentially have created a change to the 'Contract' that the clients use to consume the web service. This can lead to a client breaking unless updated at the same time.
If you are looking at a low friction way of managing model change updating database I have found that EF Code First 4.2 and EF Migrations works pretty well for me. 0.7.0.1 is reasonably stable and all available from NuGet.
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'm planning a "universal" client-server-architecture. The current structure looks like this:
Server
Asp.Net WebApp (hosted local or in azure)
EntityFrameworkCore Datalayer
WebApi with Controllers for each EF-Model, sending flat DTOs
Client
ApiClient, receiving DTOs
Viewmodels for each View (MVVM), working with several different DTOs. Relationship between Entitys need to be manually connected by Entity-IDs.
As many tutorials show, that's the way to go. But I'm unsure with some things.
When calling my Api from my ViewModel, i need multiple calls (one for each entity i need). Wouldn't it be faster to just create a ApiController for my ViewModel that gives me everything i need in one call? That's against common patterns i guess, but what speaks against it? The whole client-side logic is executed on the server and the client stays clean and dumb.
The comfortable Linq-syntax of entity-framework is not useable on the client side. Is there a comparable thing wrapping all the "receive-dto-and-create-relations" stuff?
I think you can abstract those ideas about architecture that your read on the internet, a good architecture is actually the one which can solve your problems in a more effective way.
My advice is to not stick to those architectures, open your mind, think outside the box. You could create an API Controller, or you could just create a Proxy class(http://www.dofactory.com/net/proxy-design-pattern), to abstract those api calls.
Another way, you could just join the data on the api side. It is not obligatory to return data related to a unique entity using the api. You could just create another class and model the data the way you need.
The comfortable Linq-syntax of entity-framework is not useable on the
client side. Is there a comparable thing wrapping all the
"receive-dto-and-create-relations" stuff?
Well, you can always use lambda expressions to query your data, when you are using a .net collection, it is very much like entity-framework linq, the only difference is that you are not manipulating your data direct from the database, only in memory data.
When calling my Api from my ViewModel, i need multiple calls (one for each entity i need). Wouldn't it be faster to just create a ApiController for my ViewModel that gives me everything i need in one call? That's against common patterns i guess, but what speaks against it? The whole client-side logic is executed on the server and the client stays clean and dumb.
That is NOT against common patterns. Create your API methods according to your use cases and return all data you need. Looks like you are trying to create a RESTful API but REST API doesn't have to be just plain CRUD API. Anything can be a resource.
The comfortable Linq-syntax of entity-framework is not useable on the client side. Is there a comparable thing wrapping all the "receive-dto-and-create-relations" stuff
DTO is not necessary flat. It might have other objects inside of it. If you use JSON serializer to pass data to the client your DTO should be deserialized as a Javascript object with all relations preserved. Also check underscorejs library. It has many helpful functions to work with Javascript objects in a LINQ like way.
im not sure what im looking for, and everything that i've seen so far looks like it will work till I really dive into it. I just need some pointers from the brains here. Im working an ASP.NET MVC EF5 SQL2012 project. We have a model set that isn't code first (The entities were built using the designer) and as of right now, everything is working just fine. But, we have this setup script... (Convoluted as i've ever seen) and i need to get it into something more automated. Right now, the setup script pre-populates the tables with data. look ups, reference, etc. I'm looking for a way to automate this further, without having to run this script, and even more so. To generate the database and tables automatically. Every article i've read seems to do the trick (Migrations, seeding, etc.) but the one thing they don't take into consideration, we federate services. So the actual EDMX is on a WCF Dataservice 5.6. I have access to the models and what not but the WCF service exposes an DataServiceContext which doesn't have a seed on it. Am i looking at the right stuff here? or is the only option here to have this confounded setup script (All C# Driven). This website has been detrimental to this: http://www.entityframeworktutorial.net/code-first/seed-database-in-code-first.aspx as well as this: Auto Create Database Tables from Objects, Entity Framework but i don't see how i can use these over WCF 5.6.
The short answer is that Model-First doesn't give you a seed method because they want you to use a SQL script, but you have a few choices:
Use EF PowerTools (or VS2013's EF Designer) to generate the "Code-First" model from your DB. This will allow you to seed your DB, and have finer control over how everything operates under the hood.
Use a SQL script to seed with. Generally, if you make changes to your schema, you'll re-run your recreate DB script. Create a separate script to populate your DB and keep it handy. If you feel more comfortable in code than SQL, you can make a console app (or whatever type of app you want) and keep it up to date with your schema.
If all you need is seed data, and there is a good business case to expose a method to your service consumers, you can keep Model-First, create a stored procedure to seed your DB, and expose it as an EF function. You can then expose this in your WCF service
Personally, I tend towards designing the DB myself, using VS 2013's EF6 POCO generator, then using Code-First because of the better granular control that you get with real data classes. Then I do some cleanup work, write my seed methods, etc.
This is a general architecture question, hopefully to folks out there already using EF in final applications.
We have a typical N-Tier application:
WPF Client
WCF Services
EF STE DTO's
EF Data Layer
The application loads all known business types during load time (at the same time as the user logs in) then loads a very large "Work Batch" on demand, this batch is around 4-8Mg and is composed of over 1.000 business objects. When we finish loading this "Batch" we then link everything with the previously loaded business types, etc...
In the end we have around 2K-5K business objects in memory all correctly reference so we can use and abuse LINQ on the client side, we also do some complex math on all these objects on the client side, so we really need the large graph.
The issue comes when we want to save changes to the Database. With such a large object graph, we hardly want to send over everything again through the Network.
Our current aproach, which I dislike, given the complexity of the T4 templates so far, is to detach and attach everything on update. We basically want to update a given object, detach it from the rest of the graph, send it over the network, updated it on the WCF side, and then reattach it again on the client side. The main problem is when you want to update linked objects, let's say you add something that has a reference for something that is also added, then another reference to something modified, etc. This forces a lot of client code to make sure we don't break anything.
All this is done with generated code, so we are talking about 200-800 lines of T4 code per template.
What I'm looking at right now is a way to customize serialization and deserialization of the STE's, so that I can control what is sent over the network or not, and be able to update batches instead of just a single STE. Checking references, see if those references are Unchanged or not; if not don't serialize, if yes serialize and update everything just by attaching it to the context on the WCF side.
After some studying I found 2 solutions to this method.
One is by writing a custom DataContractSerializer.
The second one is by changing the STE template created by EF and playing around with the KnownTypeAttribute, instead of generating it for each reference type, have it reference a method that inspects the object and only marks for serialization references that are not unchanged.
Has anyone ever come across this
issue before?
What solutions did you use?
What problems did you encounter down
the line?
How easy was it to maintain the
templates created?
I don't know whole application design but if you generally load the work batch to the service and then send it to the client to play with it, it looks like service layer is somehow unnecessary and you can directly load data from database (and you will get much better performance). Depending on complexity of computation you can also do some computation directly in the database and you will again get much better performance.
Your approach to save only part of the graph is abuse to STE concept. STE works in manner - you load the graph, modify the graph and save the same graph. If you want to have a big dataset for reading and save only small chunks it is probably better to load data set for reading and once you decide to update a chunk, load only the chunk again, modify it and send it back.
Interfering the internal STEs behavior is imho the best way to lost some changes in some corner / unexpected scenarios.
Btw. this somehow looks like a scenario for syncing local database with a global one - I have never done that but it is quite common in smart-clients.
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/