Question

Nutshell: The Entity Framework Provider for WCF Data Services pulls the schema namespace and EntityContainer name directly from the namespace and class name of the DbContext, respectively. This is also true for DbContexts that are developed using the code-first method.

Is there a way to modify this provider behavior a posteriori--that is, without modifying the class name or the EDM(X)?

Background/caveats/opinion: This is a handy behavior for prototyping, but in a production scenario, the class name is itself an implementation detail that should be hidden from service consumers.

Further, in my case the name cannot be changed, since I am using a framework that provides a very generic DbContext that I am then composing/extending.

Note that I am not discussing a way to create more "space" between the CLR and EDM representations of the data model. Rather, I'm looking for a way to modify the behavior of the DataService<T> extension itself, so that the internal CLR namespace and DbContext extension class name (preserved in the EDM, which is totally okay) aren't exposed externally.

The specific customization points in the service metadata (custom-ns and custom-container below):

<edmx:Edmx Version="1.0" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx">
    <edmx:DataServices m:DataServiceVersion="1.0" m:MaxDataServiceVersion="3.0" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
        <Schema Namespace="<custom-ns>" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
            <EntityType Name="EgEntity">
                .
                .
                .
            </EntityType>
            .
            .
            .
            <EntityContainer Name="<custom-container>" m:IsDefaultEntityContainer="true">
                <EntitySet Name="EgEntity" EntityType="<custom-ns>.EgEntity" />
                .
                .
                .
            </EntityContainer>
        </Schema>
    </edmx:DataServices>
</edmx:Edmx>
Was it helpful?

Solution

In code-first, you can specify the schema for tables in the SSDL with the Table annotation (look at the Schema property). Unfortunately, I don't think you can overwrite the schema namespaces used in the CSDL with either attributes or the model builder (please note that I haven't extensively researched this).

You may attempt to play with namespace aliases, although I'm not sure this would work as you intend.

In model-first and database-first, see this question which seems to answer yours. Let me know if it doesn't.

I realize this answer is not too helpful, but I would like to suggest that you specify proper namespaces for your codebase, even (especially) for production. This is because I can't immediately see why a namespace should be "hidden" in any normal scenario, but please do expand on your use-case if you disagree.

That being said, I agree that one should be able to map proper CLR namespaces to different EDM schemas for other reasons, I guess everybody is OK with using the same names as long as they make sense. By the way, don't forget vendor prefixes, especially since you're exposing these names to the network.

Note that the third-party framework namespace shouldn't be relevant as long as the context class is not sealed. Usually, entities are defined as POCOs so that's normally not a problem either. Thus, the standard solution would be to extend this generic context class in a namespace of your own, along with the entities.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top