I'm quite familiar with RIA Services, but not with WCF Data Services, and I'm wondering how to do something in the latter which I know how to do in the former.
I know examples for each data access methods on how to query database entities when the data service is backed by entity framework (or something similar).
But often enough I want to offer a queryable service method that isn't based on any database entity directly. It could be a combination from several database entities, an inherent grouping, or simply a database entity together with some additional, computed data.
Let's say I have the following classes:
// part of the model
class SomeEntity
{
public Guid Id { get; set; }
public String PropertyA { get; set; }
public String PropertyB { get; set; }
public Guid SubsidiaryKey { get; set; }
public virtual SomeSubsidiaryEntity Subsidiary { get; set; }
public virtual ICollection<SomeRelatedEntity> RelatedEntities { get; set; }
}
// part of the model
class SomeSubsidiaryEntity
{
public Guid Id { get; set; }
public String PropertyS { get; set; }
}
// not part of the model, exists only for the service layer
class SomeEntityProjection
{
public Guid Id { get; set; }
public String PropertyA { get; set; }
public String PropertyB { get; set; }
public String PropertyS { get; set; }
public Int32 RelatedEntitiesCount { get; set; }
}
The first two are part of the database model the service is using, the last is a projection entity.
The projection entity isn't part of the database - it only exists in the service layer.
With RIA Services, I can now write a query function like this:
public IQueryable<SomeEntityProjection> GetSomeEntitiesWithSomeFluff()
{
return
from e in this.DbContext.SomeEntities
select new SomeEntityProjection()
{
PropertyA = e.PropertyA,
PropertyB = e.PropertyB,
PropertyS = e.Subsidiary.PropertyS,
RelatedEntitiesCount = e.RelatedEntities.Count()
}
}
The data service method then supports client-side filtering and sorting for all four properties. All such client-side sorting and filtering will be properly delegated to the database and done there.
I couldn't find any examples of this for WCF Data Services, so my question is: Is this possible with WCF Data Services also and if so, how to do it?
You would use Data Transfer Objects (DTO) across the wire, which are similar, but not necessarily identical to your entity objects. That way they can vary independently.
Related
My DTOs are pretty simple classes.
public class PlainClass {
public int Id { get; set; }
public string Name { get; set; }
public List<PlainSubClass> SubObjects { get; set; }
}
public class PlainSubClass {
public int Id { get; set; }
public string Name { get; set; }
}
I have a repository interface, whose implementations are meant to retrieve data.
public interface IRepository
{
IEnumerable<PlainClass> PlainObjects { get; }
}
Now, I want to implement that interface in another class mocking the database and also using EF SQLite, and possibly more in the future. My mock is simple but, in trying to implement and then generate the database I'm getting an error back stating I need to designate a primary key.
Now, how should I go about doing that? Should I build out interfaces for my models and add annotations specific to each implementation? Should I -- if it's even possible -- add multiple sets of annotations to the models?
I'm new to WCF and today I have encountered a problem with DataContracts. I'm getting exception when objects are returned to client from WCF Service.
SvcTraceViewer shows the next exception:
Type
'System.Data.Entity.DynamicProxies.Person_7C797A477DD73534D4E8E743E1FCC1C75DAB75933D03B845A097A8B83F2DD748'
with data contract name
'Person_7C797A477DD73534D4E8E743E1FCC1C75DAB75933D03B845A097A8B83F2DD748:http://schemas.datacontract.org/2004/07/System.Data.Entity.DynamicProxies'
is not expected. Consider using a DataContractResolver or add any
types not known statically to the list of known types - for example,
by using the KnownTypeAttribute attribute or by adding them to the
list of known types passed to DataContractSerializer.
I have several projects in solution.
DataAccess (EntityFramework EDMX file is placed here)
Model (Entities generated by DbContextGenerator are here)
WCF Service (DataContracts are implemented in Model project)
WPF Application (runs ServiceHost)
Console Application (calls WCF project or service hosted in WPF Application)
Here is operation contract in WCF:
[OperationContract]
Person[] GetAllPersons(int version);
interface implementation:
public Person[] GetAllPersons(int version)
{
return StorageService.GetAllPersons(version);
}
The excepion is thrown when the data is recieved on the client side (ConsoleApp).
I guess the problem is related to generated entities, because they are partial classes
Here is Person class:
public partial class Person
{
public Person()
{
this.Project = new HashSet<Project>();
}
public int Id { get; set; }
public Nullable<long> AddressId { get; set; }
public string LastName { get; set; }
public string MiddleName { get; set; }
public string FirstName { get; set; }
public Nullable<long> GeoLocationId { get; set; }
public string FullGeoLocationName { get; set; }
public Nullable<long> SupervisorId { get; set; }
public Nullable<long> PositionId { get; set; }
public string Position { get; set; }
public string Office { get; set; }
public string NativeName { get; set; }
public string Location { get; set; }
public string FullName { get; set; }
public Nullable<long> PmcPersonId { get; set; }
public virtual ICollection<Project> Project { get; set; }
public virtual PersonDataVersion DataVersion { get; set; }
public virtual Workspace Workspace { get; set; }
}
I tried to mark class and it's members with [DataContract] and [DataMember] attributes, but error still happens. [KnownType(typeof(Person)] attribute also didn't help.
Is it possible to use generated entities as data contracts?
DynamicProxies indicate that you are using lazy loading and the error could be caused by the context being closed when WCF tries to serialize the object.
Try disabling lazy loading and use eager loading instead.
You should really be mapping the Person objects to data transfer objects or Poco objects. You can decorate these properties with DataMember attributes accordingly. If you must disable lazy loading you lose the benefits of the ORM and queries will be run for data you may not even use - may not be a big issue in a small system, but as systems grow it can bring them down to their knees.
I've read several articles about bunch of EF and DTO, and I need some clarification about using EF Code First and DTO in n-tier scenario with WCF.
Let's look a these classes:
public class Order
{
public int Id { get; set; }
public DateTime ShipDate { get; set; }
public ObservableCollection<OrderDetail> Details { get; private set; }
}
public class OrderDetail
{
public int Id { get; set; }
public int OrderId { get; set; }
public int ProductId { get; set; }
public decimal Quantity { get; set; }
}
When user want to edit existing order, my client application (WPF MVVM app) requests some DTO, which then being converted to Order instance. Then, user makes some changes in order through UI - e.g., changes ShipDate, removes two positions, modifies one, and adds one.
Now I want to deliver changes to the server. As far as I understand DTO concept, I need to construct some DTO type, containing info about changes has been made:
[DataContract]
public class UpdateOrderDTO
{
[DataMember]
public DateTime ShipDate { get; set; }
[DataMember]
public Collection<OrderDetail> NewDetails { get; private set; }
[DataMember]
public Collection<OrderDetail> ModifiedDetails { get; private set; }
[DataMember]
public Collection<OrderDetail> DeletedDetails { get; private set; }
}
But when, and where should I to create this DTO? I mean, I can't create it on submitting changes - there's no change tracking information in Order class.
Looks like, this object have to be created together with Order after it was requested for edition by user. This allows to track changes... Am I wrong?
Please note, that the question isn't about STEs. For some reasons, I don't want/can't use them in current project.
Thanks a lot for sharing your experience.
1) I want to know what is the recommended way to create & return a DTO for an object which has 10 attributes and I only want to return 2 with my DTO object.
2) Should DTO's have their own namespace ? If yes, how do we organize them ? Each DTO inside a single class file or all DTO's inside a single class ?
Please provide me some sample code.
DTOs are dumb objects composed of public getters/setters. I generally put them in a separate namespace called SomeProject.Dto.
public class CustomerDto {
public int Id { get; set; }
public string Name { get; set; }
public LocationDto HomeAddress { get; set; }
}
I generally try to keep the property names the same between the DTO and corresponding domain class, possibly with some flattening. For example, my Customer might have an Address object, but my DTO might have that flattened to:
public class CustomerDto {
public int Id { get; set; }
public string Name { get; set; }
public string HomeStreet { get; set; }
public string HomeCity { get; set; }
public string HomeProvince { get; set; }
public string HomeCountry { get; set; }
public string HomePostalCode { get; set; }
}
You can dramatically reduce the amount of repetitive mapping code of translating domain objects into DTOs by using Jimmy Bogard's AutoMapper.
http://automapper.codeplex.com/
Your question is very open ended. The answers are dependent on the scale of your application.
In general I create my DTO's or ViewModels in their own assembly. To get my DTO's I have some service layer take care of creating them based on my request.
If you want concrete examples take a look at some of the Asp.NET MVC examples at asp.net. While you may not be using MVC you can at least see how the ViewModels are created.
I have an MVC2 n-tier application (DAL, Domain, Service, MVC web) using a DDD approach (Domain Driven Design), having a Domain Model with repositories. My service layer uses a Request/Response pattern, in which the Request and Response objects contain DTO's (Data Transfer Objects) to marshal data from one layer to the next, and the mapping is done via help from AutoMapper. My question is this: what shape should a DTO typically take? Can it have nested/complex DTO's as well or should it strictly be a flat projection? Or possibly a mixture of both? Also, what are the main reasons for having a flat DTO vs a more complex/nested DTO?
For instance, suppose I had a domain such as the following:
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public Company Company { get; set; }
}
public class Company
{
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
}
There are three different ways I've thought of modeling the Response object.
Option 1 - the DRYest option:
public class GetEmployeeResponse
{
public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}
From the research I've done, it would be inappropriate for a DTO to take a similar shape as the domain object(s) as demonstrated above.
Option 2 - a flattened projection of the domain (anti-DRY):
public class GetEmployeeResponse
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string CompanyName { get; set; }
public string CompanyAddress { get; set; }
public string CompanyCity { get; set; }
public string CompanyState { get; set; }
}
This is more simple, like a DTO apparently should be, but ultimately makes for more DTOs.
Option 3 - a mixture of both:
public class GetEmployeeResponse
{
public EmployeeDTO Employee { get; set; }
public CompanyDTO Company { get; set; }
}
This allows for the code to be a little bit more dry, reusable and manageable, and doesn't expose my domain structure to the end user. The other main benefit is that other responses, like GetCompanyResponse could simply return CompanyDTO, without having to make a copy of all those properties, similar to option 2. What do you think? Which option of these (if any) have you taken and/or have worked for you? If these Request/Responses later get exposed as WCF service methods, does your answer change?
My personal preference would be to try and keep it flat as possible with only the required data being transfered. having said that I have used deeply nested DTO in the past because it made sense at the time and fitted the requirements. so I guess it comes down to "it depends". At the end of the day go with what makes sense for the application at hand. No point trying to shoe horn data into a DTO convention that doesn't fit what you are tying to achieve.