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>
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.
Related
I would like to know why do we use implementsInterface element in entities. I know one example where they use it to make it as assignable entity. But I could not understand what other purpose and how/why it is being used in entities.
Example: Injuryincident entity has claimantsupplier and coveragesupplier interface
I like to see it from this prespective, simplified and assuming that you have some java background:
As you probably already know it, having an entity means in the end of the day, having a Java class... Well, by using the implementsInterface element in your entity, is similar to implement an interface in you java class.
Here you have a quick example...
Consider the following:
MyEntiti.eti
<?xml version="1.0"?>
<entity
xmlns="http://guidewire.com/datamodel"
entity="MyEntity"
table="myentity"
type="retireable"/>
AnInterface.gs
package mypkg
interface AnInterface {
function doSomething()
}
AnInterfaceImpl.gs
package mypkg
class AnInterfaceImpl implements AnInterface {
override function doSomething() {
print("Hello!")
}
}
Image that you need MyEntity to have the ability of "doSomething", you just need to add the implementsInterface:
<?xml version="1.0"?>
<entity
xmlns="http://guidewire.com/datamodel"
entity="MyEntity"
table="myentity"
type="retireable">
<implementsInterface
iface="mypkg.AnInterface"
impl="mypkg.AnInterfaceImpl"/>
</entity>
By doing that, the following code must work:
var myEntity = new MyEntity()
myEntity.doSomething() //this will call the method defined in the interface-implementation
And even better, you migth let you implementation to recognize the related object of MyEntity and use it as per your needs:
package mypkg
class AnInterfaceImpl implements AnInterface {
private final var _relatedEntity : MyEntity
construct(relatedTo : MyEntity) {
_relatedEntity = relatedTo
}
override function doSomething() {
var createUser = _relatedEntity.CreateUser // you can accees to whatever you need
print("Hello!, this is the related instace of MyEntity: ${_relatedEntity}")
}
}
Hope it helps, regards!
I won't be repeating the other answer describing how it works, but I would like to mention how implementing an interface on an entity is different (and serves different purposes) compared to using enhancements.
On basic level both approaches let you add extra functionality to your entity classes. In most cases what you really want to do is just create/expand an enhancement - they are easier to write, more convenient to modify and just as effective when all you want is to just add a new function or calculated property.
When you implement an interface, you're bringing in some more serious guns. While this approach takes more work and requires creation of several files (not to mention modifying the entity itself), it gives you two important advantages over the enhancement mechanism:
The same interface can be implemented by several entities (typically each having its own implementation class) as well as non-entity classes. Objects of all such classes can then be used interchangeably in contexts expecting the interface (you can create an array of entity instances of several entities and even gosu-only wrappers/temporary objects and present it comfortably in the UI).
You can leverage polymorphism. While enhancement functions can't be overridden, the interface implementations allow you full flexibility of polymorphic OOP. You can, for example, set up a default "do nothing" implementation on high level entity that you intend to use and then add more meaningful implementations for specific subtypes meant to really make use of the new functionality.
It does have some overhead and complicates things, however. As mentioned - Enhancements are typically simpler. In practice you should ask yourself whether the extra effort of creating and implementing the interface is worth it - in many cases even situations seemingly calling for polymorphism can be handled well enough by a simple switch typeof this in the enhancement to provide all the necessary type-based logic.
In personal experience I've used interfaces in quite a few situations, but Enhancements are my first choice in overwhelming majority of cases.
As a final note I'd like to mention a delegate entity. If what you want to add to some unrelated entities is not functionality but Properties with underlying database fields, creating a delegate entity and "implement" it with the desired standalone entities. A delegate entity does work a bit like an interface (you can use entity objects implementing the delegate interchangeably in situations where the delegate is expected) and you can set-up both interface implementation and enhancements on delegate level as well.
I am using the IBM Social Business Toolkit. I have defined a connection for my Notes app via endpoints in the faces-config xml file. I wonder how I can access this file pro grammatically since I could not find a service that returns me the base url of IBM Connections.
It's useful to remember that an endpoint definition is really just creating a managed bean. The managed bean has a variable name you refer to it - the managed-bean-name property. You can access this directly from SSJS or via ExtLibUtil.resolveVariable() in Java. The definition also tells you the Java class that's being used, e.g. com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint. That really gives you all the information you need to get or set the properties.
So from SSJS you can just cast it to the class name, e.g.
var myService:com.ibm.sbt.services.endpoints.ConnectionsBasicEndpoint = connections
So the bit after the colon will be the managed-bean-class value and the bit after the equals sign will be the managed-bean-name. In Java, you can use
ConnectionsBasicEndpoint myService = (ConnectionsBasicEndpoint) ExtLibUtil.resolveVariable(ExtLibUtil.getXspContext().getFacesContext(), "connections");
You'll then have access to all the methods of the class, so you should be able to retrieve what you need.
The properties are part of the Java class, who are referred to in the Faces-Config.xml. So get the class by his fully qualified name or by bean name and set or get the properties
I think the best route will most likely be what Paul is suggesting: resolve the variable by its name and use the getters to get the effective properties that way.
Sven's suggestion is a good one to keep in mind for other situations. By accessing the faces-config.xml file as a resource, you could load it into an XML parser and find the values using XPath. I'm doing much that sort of technique in the next version of the OpenNTF Domino API, which will have a set of methods for manipulating the Faces config. However, one key aspect there is that reading the XML file directly will just get you the string values, which may be EL expressions, whereas going the resolveVariable route will get you the real current properties.
We use early-bound class for development. But occasionally we use attribute names.
There is a way to do it using reflections, but reflections are not allowed in sandbox plugins.
What are the approaches to getting an attribute from proxy types without relying on reflections?
Opportunity.OpportunityId.AttributeName
You have a couple options:
You can use a RetrieveEntityMetadata to the list of attributes that the entity contains. You won't be able to use any early binding here, but you can inspect the results at run time to see what are valid attributes for the entity.
You could also create a simple utility that uses reflection to auto-generate a class or enum that contains the list of attributes before you actually deploy. Just add the class to your plugin dll and you'd have the benefits of early binding of entity attributes when developing your plugin, without having to do reflection at runtime.
It's easier to generate tables and default classes with liferay's service builder.
But it is bit difficult for me to understand the hierarchy of classes generated by it.
Also the exact use of each class other than modifying LocalServiceImpl class as per our need by adding our own functionality.
I have gone through Service Builder doc. So I got some basic knowledge but would like to get more on this.
Even the link "Liferay Service Builder" was useful but outdated with current Liferay version. So Does anyone have update on above link or nice info explaining hierarchy with example/diagram?.
Any help is appreciated.
Thanks.
To implement the foreign key concept in liferay, you have to apply your own coding logic since the implementation of FK are not available in service builder. So I guess you need to put some code.
Read some forums related to service builder on liferay website. It will give you better exposure.
Read Liferay In Action. It is a good book
Here is What I obeserved In Liferay 6.1.
com.liferay.portlet.p_name.model:
This has interfaces and classes related to (table entity related to) this portlet.
For example com.liferay.portlet.announcements.model will have
Interfaces:
AnnouncementsEntry
AnnouncementsEntryModel
AnnouncementsDelivery
AnnouncementsDeliveryModel
AnnouncementsFlag
AnnouncementsFlagModel
Classes:
And In classes section, You will find wrapper classes and soap classes for each entity like:
AnnouncementEntryWrapper
AnnouncementEntrySoap
AnnouncementFlagWrapper
AnnouncementFlagSoap
AnnouncementDeliveryWrapper
AnnouncementDeliverySoap
Also for few Entity, you will find Classes for Constant entries like
AnnouncementsEntryConstants, AnnouncementsFlagConstants etc.
com.liferay.portlet.p_name.service:
This has classes and interfaces related to (table entity related to) this portlet.
For example com.liferay.portlet.announcements.service will have
Interfaces:
AnnouncementsEntryService
AnnouncementsEntryLocalService
AnnouncementsDeliveryService
AnnouncementsDeliveryLocalService
AnnouncementsFlagService
AnnouncementsFlagLocalService
Classes:
And In classes section you will have Util and Wrapper classes.
AnnouncementsEntryServiceUtil
AnnouncementsEntryServiceWrapper
AnnouncementsEntryLocalServiceUtil
AnnouncementsEntryLocalServiceWrapper
and so on.....
So In short following is the structure I observed in Liferay
[In Model, I:+Model,(ModelName), C:Soap, Wrapper and Constants]
[In Service, I:Service,LocalService ; C:ServiceUtil,ServiceWrapper,LocalServiceUtil and LocalServiceWrapper]
[In Persistence, I:Finder(BlogsEntryFinder),Persistence(BlogsEntryPersistence); C:Util(BlogsEntryUtil, BlogsEntryFinderUtil)]
Note:
I --> Interface
C --> Class
I want to serialize an Entity Framework Self-Tracking Entities full object graph (parent + children in one to many relationships) into Json.
For serializing I use ServiceStack.JsonSerializer.
This is how my database looks like (for simplicity, I dropped all irrelevant fields):
I fetch a full profile graph in this way:
public Profile GetUserProfile(Guid userID)
{
using (var db = new AcmeEntities())
{
return db.Profiles.Include("ProfileImages").Single(p => p.UserId == userId);
}
}
The problem is that attempting to serialize it:
Profile profile = GetUserProfile(userId);
ServiceStack.JsonSerializer.SerializeToString(profile);
produces a StackOverflowException.
I believe that this is because EF provides an infinite model that screws the serializer up. That is, I can techincally call: profile.ProfileImages[0].Profile.ProfileImages[0].Profile ... and so on.
How can I "flatten" my EF object graph or otherwise prevent ServiceStack.JsonSerializer from running into stack overflow situation?
Note: I don't want to project my object into an anonymous type (like these suggestions) because that would introduce a very long and hard-to-maintain fragment of code).
You have conflicting concerns, the EF model is optimized for storing your data model in an RDBMS, and not for serialization - which is what role having separate DTOs would play. Otherwise your clients will be binded to your Database where every change on your data model has the potential to break your existing service clients.
With that said, the right thing to do would be to maintain separate DTOs that you map to which defines the desired shape (aka wireformat) that you want the models to look like from the outside world.
ServiceStack.Common includes built-in mapping functions (i.e. TranslateTo/PopulateFrom) that simplifies mapping entities to DTOs and vice-versa. Here's an example showing this:
https://groups.google.com/d/msg/servicestack/BF-egdVm3M8/0DXLIeDoVJEJ
The alternative is to decorate the fields you want to serialize on your Data Model with [DataContract] / [DataMember] fields. Any properties not attributed with [DataMember] wont be serialized - so you would use this to hide the cyclical references which are causing the StackOverflowException.
For the sake of my fellow StackOverflowers that get into this question, I'll explain what I eventually did:
In the case I described, you have to use the standard .NET serializer (rather than ServiceStack's): System.Web.Script.Serialization.JavaScriptSerializer. The reason is that you can decorate navigation properties you don't want the serializer to handle in a [ScriptIgnore] attribute.
By the way, you can still use ServiceStack.JsonSerializer for deserializing - it's faster than .NET's and you don't have the StackOverflowException issues I asked this question about.
The other problem is how to get the Self-Tracking Entities to decorate relevant navigation properties with [ScriptIgnore].
Explanation: Without [ScriptIgnore], serializing (using .NET Javascript serializer) will also raise an exception, about circular
references (similar to the issue that raises StackOverflowException in
ServiceStack). We need to eliminate the circularity, and this is done
using [ScriptIgnore].
So I edited the .TT file that came with ADO.NET Self-Tracking Entity Generator Template and set it to contain [ScriptIgnore] in relevant places (if someone will want the code diff, write me a comment). Some say that it's a bad practice to edit these "external", not-meant-to-be-edited files, but heck - it solves the problem, and it's the only way that doesn't force me to re-architect my whole application (use POCOs instead of STEs, use DTOs for everything etc.)
#mythz: I don't absolutely agree with your argue about using DTOs - see me comments to your answer. I really appreciate your enormous efforts building ServiceStack (all of the modules!) and making it free to use and open-source. I just encourage you to either respect [ScriptIgnore] attribute in your text serializers or come up with an attribute of yours. Else, even if one actually can use DTOs, they can't add navigation properties from a child object back to a parent one because they'll get a StackOverflowException.
I do mark your answer as "accepted" because after all, it helped me finding my way in this issue.
Be sure to Detach entity from ObjectContext before Serializing it.
I also used Newton JsonSerializer.
JsonConvert.SerializeObject(EntityObject, Formatting.Indented, new JsonSerializerSettings { PreserveReferencesHandling = PreserveReferencesHandling.Objects });