Do I have to explicitly add the [Include] attribute for any entities that has ICollection property so that result LoadOperation callback will populate my entity with its collection?
Querying the data from the Service is fine, but when being passed to the LoadOperation it doesn't add the collection of a certain entity. Does it have something to do with serialization/deserialization from the service message?
If yes, what is the reason why? I have used EF with DbContext.Includes in WPF but I did not have any issues with my T4 template generated items when I wanted to query my entity's collection.
The [Include] attribute is required to advise the WCF marshaller to serialize related entities. Specifically, MSDN advises
this attribute specifies that the association should be part of any
code-generated client entities, and that any related entities should
be included when serializing results to the client.
You will still need to use the query.Include() on your DbContext to retrieve the related data from the database.
Related
Let's say we have a User entity. Should I have two smaller services (User and Users)? Or one larger service that deals with both a collection of Users and an individual User? If it is the latter, is it best practice to name the service User or Users?
I use one service per entity that houses the collection, methods used by the entity collection controller, and methods used by the individual entity's controller. This works for my team as we follow the repository pattern in our server code. I save the collection in the service because it is accessed often, and parts of the collection are nice to share in other area's like to keep a count in the menu, or create a relational list in another controller. The individual entity is typically only accessed by the controller for the view, and can be disposed of when the route is changed as long as the list item in the controller was updated if the entity was changed.
The only time I used separate services was one edge case where the customer wanted an entity to save state if the route was changed without persisting the entity to the server or cache. The entity needed to be saved somewhere so that was reason enough to create a service for the individual entity.
I do use a separate service per entity to manage http requests. So each entity does have two services, one to manage the collection and all crud+ functionality, and the other for http for separation of concerns.
I have one table with 20 columns, I want only display this data on UI (not add/edit/delete). I want to know, where is appropriate place to create DTO class for this table, in DAL project or in Web project?
You can create DTO's in the web project, map the entity to it, and have the domain service call return it. You could also just return the entity and mark the Properties you don't want displayed with [Display(AutoGenerated = False)].
If you are using LINQ to Entities or LINQ to SQL, you could use projection to limit what is returned from the WCF service request and work with an anonymous type. Use the LINQ select method. Then you wouldn't have to create a DTO object.
If the UI you mentioned is Silverlight, WCF Data Services (EDIT: and WCF RIA Services does not) support projection across a service.
LINQ example:
context.Displays
.OrderBy(d => d.Title)
.Select (
d =>
new
{
Title = d.Title
})
Julie Lerman says to use the QueryView in an MSDN Magazine article. That might be the solution.
If you only wants to show data, the better approach would be the create a View and directly get it on Client Side. This will be much more cleaner and easier.
I'm making a Silverlight 4 application with WCF RIA Services.
On the server side (the *.Web project), I have an Entity Model that's auto-generated from a SQL Server database.
On the client side, I have the domain service and proxy objects that are generated by Visual Studio for use in Silverlight assemblies.
I want to add custom properties to the model (preferably on the server side).
Say I have Contact, Company, and Address tables, which are linked by foreign keys (but not necessarily actual foreign key constraints). I want to add a property that will return a Contact's Company's Address object.
I have been attempting to do this by making a partial class to extend the Contact class, and adding a CompanyAddress { get; } property. But I have no idea what I need to do with the new property in order to make it propagate to the auto-generated code on the client side. Are there specific attributes I have to add to the property? Do I have to register it somewhere so that the code generator will know about it?
Does this have to be a Navigation Property or can it be something simpler?
And is this even the best way to do things, or should I give up on extending the server-side model and just do it on the client side? (If I do it on the client side, I face the problem of not having access to the context object inside the individual Entity-derived classes.)
I have never used Silverlight or RIA services but I guess it will be quite similar. When you create EF model and you have entities related by foreign key (there has to be relation), each entity related to other entity will contain something called navigation property. So in your scenario Contact should contain property named Company and Company shoud contain property called Address. You can isntruct EF to load those navigation properties by using Include on ObjectSet or by lazy loading (not good idea in WCF). Than if you send Contact by WCF to the client, Company and Address will be send as well.
Your approach has one big problem. Your property contains only getter - such property is not serialized.
I have a google app engine app where I would like to extend one of my Entity definitions. How would I ensure existent entity objects get the new fields properly initialized? Would the existent objects, the next time I query them, simply have default values? I'd like to add a StringListProperty.
If you add a new property to your model, existing entities will have the default value for it when you load them, if you supplied a default. They won't show up in queries for that value until you fetch them and store them again, though.
You will have to add the property to all of your existing entities, one by one.
You don't mention which language or API you are using. The exact details of the procedure will vary with your situation.
In general, the safest way to do this is to load up each entity with a API that doesn't validate your entities. In python, you can use Expando models. In java, you can use the low level datastore API. (trying this with JDO or JPA may not work) You now need to iterate through all existing entities. (try the new Mapper API to do this with relatively little fuss). For each entity, you will load it, add your new property, then put/save it back to the datastore. Now you can safely go back to a framework that validates your entities, like JDO or non-expando models.
This method applies to modifying the type of a property or deleting a property as well.
I would like to ".NET RIA Service"-enable my custom data model (BLL/DAL). Are there interfaces I have to implement to enable this functionality or all I have to do is create a Domain Service? If so, how can tell my Domain Services about my BLL? For Astoria, one has to implement IQueryable and IUpdatable interfaces for CRUD capabilities. Is this the same for RIA Services?
All you have to do is create a DomainService. The DomainService will have methods like GetMyObjects() and InsertObject(MyObject object) that either return or accept objects for your BLL - that's how you tell the DomainService about your classes. Your Get***() methods in the DomainService need to return a generic IQueryable, but you shouldn't need to implement it yourself. There's an AsQueryable() extension method that I believe you can use on a generic List, IEnumerable or Array that will convert any list of objects to an IQueryable. It should be reasonably easy to create a DomainService to wrap your existing BLL. Brad Abrams's has a great post describing this scenario: http://blogs.msdn.com/brada/archive/2009/07/22/business-apps-example-for-silverlight-3-rtm-and-net-ria-services-july-update-part-6-poco-and-authentication-provider.aspx