How i can use Inheritance in Entity Framework with .NET RIA Services?
Problem:
if there is inheritance in EF, silverlight application don't compiled.
Can you help me?
This:
Type 'Common.Individual' is a direct or indirect subclass of Type 'Common.Customer'. DomainServices cannot return a Type that is a subclass of another Type returned from the same DomainService.
...does not mean "no inheritance support." It does mean that (in the current version of RIA services) you can't return both a parent and a child type to the client.
That is a limitation, and it's a limitation you have to live with in RIA Services for now. That said, I don't think it's as big as a limitation as the thread you reference implies. Is not the same as saying you cannot use inheritance at all. Also, I think that inheritance tends to be overused in entity mapping for reasons I explain in great detail in this presentation.
So while I can't fix the limitation, my suggestions are:
Use composition instead of inheritance when appropriate (cf. the presentation referenced above).
When you must use inheritance, RIA Services will require that you don't return the parent type.
Related
When using the SQLEntityConnection F# type provider, the generated types provided by this type provider may not be used by other F# assemblies and, by implication, any other assemblies, such as a separate ASP.Net application, console application, C# program, etc. So the type provider must be marked internal or private.
Moreover, functions that use the type provider may not be more accessible than the types provided by the type provider. So such functions must also be marked internal or private.
What is the proper way to map these types, which by necessity must be marked internal or private, to something public which can be used outside the same assembly?
A simple pattern using Entity Framework is to retrieve an entity from a DbContext, update some properties, call some methods, update some child entities, etc., then call SaveChanges() on the DbContext. Since the retrieved entity is still attached to the DbContext and the DbContext is still in scope, the changes are tracked automatically and the update is simple.
Is the same workflow possible using the SQLEntityConnection F# type provider? My guess is no if the entity needs to be updated outside the assembly where the TypeProvider is used, e.g. in a C# MVC project, given the limitations I mentioned in the original post. What is a comparable approach to doing basic CRUD operations using the SQLEntityConnection type provider? Unfortunately, the official documentation is very lacking in basic operations. Maybe an alternate type provider is a better, more functional choice.
We are in a process of designing an application with approx 100 tables and complicated business logic. Windows Forms will be used on the client side and WCF services with MSSQL on the server.
Custom DTOs are used for client-server communication, business entities are not distributed.
Which variant of Entity Framework to use (and why):
EF 4.0 EntityObjects
EF 4.0 POCO
EF 4.1 DbContext
Something else
Database-first approach is a requirement.
Also, is it worth implementing a Repository pattern? It seems a bit redundant, as there is one level of abstraction in the mapping itself and another one in the use of DTOs. I'm currently leaned towards using auto-generated extendable repositories for each entity returning IQueryable, just to have a place to put common queries, but still allowing querying entity model directly from the Service Layer.
Which variant to use? Basically once you have custom DTO the only question is do you want to have control over entities code (their base class) and make them independent on EF? Do you want to use code first? If the answers to all questions are no then you can use EntityObjects. If you want to have entities persistence ignorant or use custom base class you should go to POCO. If you want to use code first or new DbContext API you will need EF 4.1. Some related topics:
EF 4.1 Code-first vs Model/Database-first
EF POCO code only VS EF POCO with Entity Data Model (this was related to CTP)
ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
EF Model First or Code First Approach?
There are more things to consider when designing service layer. You should be aware of complications you will have to deal with when using EF in WCF. Your service will provide data to WinForms application and it will work with them in "detached mode". Once user will do all changes he wants to do he will post data back to the service. But here comes the problem - you must tell EF what has changed. If you for example allow user to change order with all its order items (change quantity in items, add new items, delete some items) you must say EF exactly what has changed, what was added and what was deleted. That is easy when you work with single entity but once you allow user to change object graph (especially many-to-many relations) then it is quite tough. The most common solution is loading the whole graph and merge the state from incoming DTOs to loaded and attached graph. Other solution is using Self tracking entities instead of EntityObjects/POCOs + DTOs.
When discussing repositories I would refer you to this answer which refers many other answers discussing repositories, their possible redundancy and possible mistakes when using them just to make your code testable. Generally each layer should be added only if there is real need for the layer - due to better separation of concerns.
The main advantage of POCOs is that those classes can be your DTOs, so if you've already got custom DTOs that you're using, POCO seems a bit redundant. However, there are some other advantages which may or may not have value to you, since you didn't mention unit testing as a requirement. If you plan to write unit tests, then POCO is still the way to go. You probably won't notice much difference between 4.0 POCO and 4.1 since you won't be using the code-first feature (disclaimer: I've only used 4.0 POCO, so I'm not intimately familiar with any minor differences between the two, but they seem to be more or less the same--basically I was already using POCO in 4.0 and haven't seen anything that's made me want to update everything to use 4.1).
Also, depending on whether you plan to unit-test this layer, there's still value in implementing the repository/unit of work patterns when using Entity Framework. It serves to abstract away the data access logic (the context), not the entities themselves, and allows you to do things like mocking your context in unit tests. What I do is copy the T4 template for my context and use it to create the interface, then edit the T4 template for the context and have it implement that interface and use IObjectSet<T> instead of ObjectSet<T>. So instead of:
public class MyEntitiesContext
{
public ObjectSet<MyClass> MyEntities
...
}
I end up with:
public interface IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities;
}
and
public class MyEntitiesContext : IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities
...
}
So I guess it really comes down to whether or not you plan to write unit tests for this layer. If you won't be doing anything that would require mocking out your context for testing, then the easiest thing to use would probably be 4.0 EntityObjects, since you aren't planning to pass your entities between layers and it would require the least effort to implement. If you plan to use mocking, then you'll probably want to use POCO and implement repository/unit of work.
Is it possible to have a generic server-side query like the following?
public IQueryable<TContact> GetContactsOfType<TContact>()
where TContact : Contact
{
return ObjectContext.Contacts.OfType<TContact>();
}
I want RIA to recognize and regenerate for me this query at the client project.
Note: Contact is an abstract class that has some subclasses. I'm using Entity-Framework generated EntityObjects.
The error I get when I'm trying compile: Type 'TContact' is not a valid entity type. Entity types must have a default constructor.
By default WCF RIA Services does not expose generic domain service methods for the client to call. RIA is strongly-typed to make it easier to reason about the behavior.
But there seems to be a workaround with defining your on DomainOperationEntry and a custom DomainServiceDescriptionProvider. Colin Blair posted an answer here. That seems to match what you are expecting.
Update: I tried what you want im my silverlight project and defined a generic query method on my domain service. The project compiles successfully but the generic parameter is ommited on the client side.
Instead, I would suggest to use Text Template of EF generator to create RIA Services operations for every entity. And use a pattern of name like how RIA Services uses "Get" <Type> Query, and other methods.
According to Initial POCO Design 1-Pager
Persistence Ignorance refers to being
able to allow the developer to write
and test domain objects in a way that
is entirely independent of fundamental
requirements and assumptions that may
be made by the infrastructure service
(in this case, the Entity Framework).
Such requirements / assumptions may
often include:
The need to implement a specific interface (for e.g., IPOCO)
Inheritance from a base class
Providing specific constructors
Object Instantiation/Construction requirements – use a specific factory
for instance**
The need for metadata or mapping class or property Attributes
The need to use specific relationship mechanisms
This amounts to being able to use
Plain Old CLR Objects (POCO) so that a
developer can author their domain
objects free of all assumptions and
requirements imposed by the framework.
Using this approach, once the domain
objects are ready to their
satisfaction, the developer can use
these classes with the Entity
Framework in order for relational
database access and persistence.
As of right now (CTP5), is there any way at all to reconstitute a poco using a parametrized constructor? If not, it's hard to see how the Entity Framework can be said to offer persistence ignorance.
You can have as many parameterized constructors as you want, so long as the framework has access to a parameter-less one, which is available by default if you you have no constructors, or if you provide one in addition to the parameterized ones you create.
Aside from faster development time (Visual Studio 2010 beta 2 has no T4 templates for building POCO entity objects that I'm aware of), are there any advantages to using the traditional EntityObject entities that Entity Framework creates, by default? If Microsoft delivers a T4 template for building POCO objects, I'm trying to figure out why anybody would want to use the traditional method.
You're asking two questions at the same time, it seems. Code-only versus model-first and EntityObject parent type versus arbitrary parent type. You get designer support with model-first, regardless of parent type. Aside from designer support, you can also use precompiled views with model-first. That can significantly help performance.
Having EntityObject as a parent can be an advantage over so-called "POCOs" (which are usually proxy bases, not "plain" objects), because the runtime type of your entities are the exact type you expect, rather than a runtime-generated subtype.
Also, unlike other ORMs which have minimal to no LINQ support, the Entity Framework has rich LINQ support, allowing you to project onto real POCO types. Therefore, it is possible to build truly persistence-ignorant presentations without having to care about what the base type of your entities are. You are not stuck with whatever type comes out of the ORM blackbox.
EntityObject allows for private properties which are persisted to the database. Using proxy types requires that those properties are at least protected and must be virtual. Therefore, EntityObject may allow for better encapsulation.
I'm not trying to suggest, by the way, that there aren't advantages to using proxies; I'm just trying to answer your question about what the advantages of EntityObject are.
I think the only benefit is designer support. Can't find any other benefits in using non-poco entities.