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
Related
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 am trying to create a WCF Data Service that returns objects that look somewhat like my POCOs; they differ insofar as they have a single property which is computed when a query is called.
In other words say I have a POCO Film. I want to be able to query for Films which gives me Films with each with an added property 'IsAllowedToWatch'. The value of 'IsAllowedToWatch' is determined by my authentication state and the number of users currently watching that film.
I'm using Code-First EF4 and WCF Data Services. Can anyone suggest the best way of doing this?
I've solved this problem but the solution was rather convoluted. I had to employ a custom IQueryProvider that mediated between my custom business type and the database type. It all got rather ugly!
I´m new to ORMs and I have a new project I´ll do in .Net MVC.
In the Model Layer I´ll create my classes: Videos and I´ll work with APIs as a DataLayer (BrightCove & YouTube APIs).
So, I dont have a Relational Database as a Data Layer. Is it possible to work with an ORM (as Subsonic)?
Thanks!
Pretty sure this isn't do-able. Or at least it's not the intention of an ORM.
If you're dealing with an api you'd be making a call and getting back a result yes? or you'd make a call and then get values from properties?
Either way there really isn't anything for the ORm to map from. It has no idea on calling api's etc. They are given objects that they can interpret using reflection (i assume) etc.
So I think you'll need to create an object yourself from the API, in which case you probably don't need an ORm in this case. Unless you create your API model in a layer of some sort and then use an ORM to translate to a model used by the application. This would be a better solution because if the API model changes the changes to your code would be minimal.
There is a .NET API for Youtube that provides classes for videos as well as data access methods to get data from Youtube. I think unless you have a good reason to roll your own, you might consider using their .NET API and directly using or extending the classes they provide. If you want to abstract out the data access, you could create your own Video class with just the properties you need and implement your own video repository which uses Youtube's API to hydrate instances of your class.
In the SubSonic code (just download it from github) there is a neat method in the SqlQuery class that is called "ExcecuteTypedList()".
It is just a small method that uses reflection to map a result from a DataReader to a generic class. It's simple but brilliant.
You could look at the code and modify it for yourself to fit your needs.
It basically does the following if you call ExecuteTypedList()
create an instance of your class
for the parameter "Test" it tries to load the property "Test of the class instance
Sets the value
I'm getting started on a new MVC project where there are some peculiar rules and a little bit of strangeness, and it has me puzzled. Specifically, I have access to a database containing all of my data, but it has to be handled entirely through an external web service. Don't ask me why, I don't understand the reasons. That's just how it is.
So the CRUD will be handled via this API. I'm planning on creating a service layer that will wrap up all the calls, but I'm having trouble wrapping my head around the model... To create my model-based domain objects (customers, orders, so on..) should I:
Create them all manually
Create a dummy database and point an ORM at it
Point an ORM at the existing database but ignore the ORM's persistence in lieu of the API.
I feel like I've got all the information I need to build this out, but I'm getting caught up with the API. Any pointers or advice would be greatly appreciated.
Depending on the scale of what you're doing option 3 is dangerous as you're assuming the database model is the same as that exposed by the external service. Options 1 and 2 aren't IMHO much different from each other - in either case you'll have to decide what your objects, properties and behaviours are going to be - it just boils down to whether you're more comfortable doing it in classes or database tables.
The key thing is to make sure that the external service calls are hidden behind some sort of wrapper. Personally I'd then put a repository on top of that to handle querying the external service wrapper and return domain objects.
In general, ORMs are not known for their ability to generate clean domain model classes. ORMs are known for creating data layers, which you don't appear to need in this case.
You could probably use a code generation tool like T4 to code generate a first pass at your domain model classes, based on either the web service or the database, if that would save you time. Otherwise, you probably would just manually create the domain objects. Even if you code generate a first pass at your domain objects, it's unlikely there is a clean 1-1 mapping to your domain objects from either the database or web service, so you will likely need to spend significant time manually editing your code generated domain classes anyway.
This is concerning an enterprise application with a very generic database (all objects are identified using data in the database and internationalized/globalized/localized).
Make a model for Repository pattern, then make (generate 1:1) another model for DB access (LINQ2SQL or EF) and use the later as repository model data access layer?
Just use L2S/EF/NHibernate model directly, mapping model to DB and opening persistence layer?
Will this dual model idea (repository pattern) popup problems making dynamic stackable LINQ search queries possible when using L2S/EF model directly in a dual model environment?
Please advise.
As long as you are exposing IQueryable objects in your repository, you should have no problem stacking queries in the manner you suggest.
I would be cautious about using Entity Framework for this, since lazy loading is not supported in the way you might expect. Linq to SQL will handle lazy loading without problems.
For more information about lazy loading in the Entity Framework, see: http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx
Take a look at sharp architecture.
Regarding returning IQueryable from your repository objects, it is my opinion that doing such blurs a proper separation of concerns in your application. I'm all for working with IQueryable within your data access layer but once you start returning objects as IQueryable you provide the opportunity for your controllers and/or views to start meddling with data access. Such may even negatively impact the testability of your application as well.