I've got an application set up with RIA Services, Entity Framework 4, and Silverlight 4. It is set up in the standard fashion prescribed on MSDN here: Walkthrough: Creating a RIA Services Solution
I've written a new method (or property) against one of the entity objects which resides on the server; I would like this method (or property) to also be generated (automagically) on the client. i.e.
I have a table in my database called Customer which has two fields: FirstName and LastName
(ASP.NET project - server side) EF has created a corresponding partial class called Protocol that has two properties: FirstName and LastName
(ASP.NET project - server side) In another file, I'm using the partial class mechanism to define a method (or property) to return the FirstName and LastName together in a string, e.g.
public function ReturnFullName() as String ...
public property FullName() as String ...
Is there a way for ReturnFullName() and FullName() to be generated in on the client side (my Silverlight application)? Or do I have to implement the method / property on the client side as well?
Create a .shared.cs or .shared.vb file with a partial class of the entity in it.
For example:
Partial Public Class Persoon
Public Function GetFullName() As String
Return Me.Voornaam & " " & Me.Naam
End Function
End Class
public partial class Persoon
{
public string GetFullName()
{
return this.Voornaam + " " + this.Naam;
}
}
It will then generate on client side to.
Methods in your Domain objects on the server side are not generated on the client side. (One reason for that is that obviously you could use .NET Framework features in these methods that are not available in Silverlight.) Properties are just copied with their signature, using class variables.
A solution to that problem is having a partial .cs file for your Customer class where you define these methods and create a link to that file in your Silverlight project. Of course, you can only use libraries in the using statements that are also available in Silverlight.
Related
I am using Entity Framework on a project, but am finding the large queries, especially those which use LEFT joins, to be very tedious to write, and hard to debug.
Is it common, or accepted practice, to make use of Views in the database, and then use those views within the EntityFramework? Or is this a bad practice?
the question is not very clear but there is no absolute right or wrong in Software. it all depends on your case.
there is native support for views in ef core but there is no native support for views in EF < 6. at least not in the current latest version 6.3. there is, however, a work around to this. in database first you would create your view via sql normally and when you reverse engineer your database, EF will treat your view as a normal model and will allow you to consume it regularly as you would do in a normal table scenario. in Code First it's a bit more tedious. you would create a POCO object that maps to the columns in your view. notice that you need to include an Id in this POCO class. for example
public class ViewPOCO
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.None)]
public Guid Id {get;set;}
public string ViewColumn1 {get;set;}
... etc.
}
you would add this POCO class in your DbContext
public class MyDbContext : DbContext
{
public virtual DbSet<ViewPOCO> MyView {get;set;}
}
now you will normally apply the command of adding migration through the package manager console
Add-Migration <MigrationName> <ConnectionString and provider Name>
now in the migration up and down you will notice that EF treats your Model as table. you would clear all of this and write your own sql to add/alter the view in the up and drop the view in the down method using the Sql function.
public override void Up()
{
Sql("CREATE OR ALTER VIEW <ViewName> AS SELECT NEWID() AS Id, ...");
}
public override void Down()
{
Sql("DROP VIEW <ViewName>");
}
First create your view.
Update Your .edmx File.
then use like this.
using (ManishTempEntities obj = new ManishTempEntities())
{
var a = obj.View_1.ToList();
}
I am looking for a maven plugin that will auto generate EntityProxy interfaces from my domain classes.
The class could implement the various interfaces to be generated and then each field or accessor method could use an annotation.
public class MyDomainObject implements MyDOProxyFoo, MyDOProxyBar {
#ExposedBy({MyDOProxyFoo.class})
public String foo;
#ExposedBy({MyDOProxyBar.class})
public String bar;
#ExposedBy({MyDOProxyFoo.class,MyDOProxyBar.class})
public String foobar;
...
}
Then the getters/setters for the respective fields would be in the respective generated interfaces.
You could do something like a readonly attribute in the annotation to only expose a getter in the specified interfaces.
...
#ExposedBy({MyDOProxyBar.class}, readOnly = {MyDOProxyFoo.class})
public String bar;
...
I could run something like
mvn rfproxygen:generateproxies
and I would have all my proxy interfaces nicely created in the generated sources directory.
I guess the argument is deciding wether you should have service data binding logic in your domain model.
I don't know a maven plugin that is capable of generating proxies but there is an issue addressing this for GWTP. Maybe this will of interests for you if it's finished.
Trying to implement a domain service in a SL app and getting the following error:
Parameter 'spFolderCreate' of domain method 'CreateSharePointFolder' must be an entity type exposed by the DomainService.
[EnableClientAccess()]
public class FileUploadService : DomainService
{
public void CreateSharePointFolder(SharePointFolderCreate spFolderCreate)
{
SharePointFolder spf = new SharePointFolder();
spf.CreateFolder_ClientOM(spFolderCreate.listName, spFolderCreate.fileName);
}
[OperationContract]
void CreateSharePointFolder(SharePointFolderCreate spFolderCreate);
[DataContract]
public class SharePointFolderCreate
{
private string m_listName;
private string m_fileName;
[DataMember]
public string listName
{
get { return m_listName; }
set { m_listName = value; }
}
[DataMember]
public string fileName
{
get { return m_fileName; }
set { m_fileName = value; }
}
}
So am I missing something simple here to make this all work?
It may be that the framework is inferring the intended operation because you have the word "Create" prefixing the function name (CreateSharePointFolder). Details of this behaviour can be found here
Although that is all fine for DomainServices and EntityFramework, following the information in that article, it can be inferred that methods beginning "Delete" will be performing a delete of an entity, so must accept an entity as a parameter. The same is true for "Create" or "Insert" prefixed methods. Only "Get" or "Select" methods can take non-entity parameters, making it possible to pass a numeric id (for example) to a "Get" method.
Try changing your method name temporarily to "BlahSharePointFolder" to see if it is this convention of inferrance that's causing your problem.
Also, as there is no metadata defined for your SharePointFolderCreate DC, you might need to decorate the class (in addition to the [DataContract] attribute) with the [MetadataType] attribute. You will see how to implement this if you used the DomainServiceClass wizard and point to an EF model. There is a checkbox at the bottom for generating metadata. Somewhere in your solution.Web project you should find a domainservice.metadata.cs file. In this file, you will find examples of how to use the [MetadataType] attribute.
For the RIA WCF service to work correctly with your own methods, you need to ensure that all entities existing on the parameter list have at least one member with a [Key] attribute defined in their metadata class, and that the entity is returned somewhere on your DomainService in a "Get" method.
HTH
Lee
Using silverlight 4, with RIA Services Toolkit May 2010.
I have an Entity Data Model (.edmx) which contains a FK reference.
In my DomainContext Service class (which references my .edmx) I modified my GET method to include Include("FK_ENTITY_TABLE_NAME"):
public IQueryable<PARENT_ENTITY> GetPARENT_ENTITY()
{
this.ObjectContext.PARENT_ENTITY.Include("FK_ENTITY_TABLE_NAME");
}
In my DomainContext Service Metadata class (.metadata.cs) named "internal sealed class PARENT_ENTITYMetadata" I added the [Include] attribute to the
property which references my FK entity:
[Include]
public FK_ENTITY_TABLE_NAME { get; set; }
My generated (.g.cs) ria service proxy file contains the following DataContract with XmlIgnore:
private EntityRef<FK_ENTITY_TABLE_NAME_PARENT_ENTITY> _fk_entity_table_name;
public sealed partial class PARENT_ENTITY : Entity
{
...
[Association("FK_ENTITY_TABLE_NAME_PARENT_ENTITY", "entity_id", ",entity_id", IsForeignKey=true)]
[XmlIgnore()]
public FK_ENTITY_TABLE_NAME FK_ENTITY_TABLE_NAME
{
...
Therefore, when I use the XmlSerializer / DataContractSerializer and on my PARENT_ENTITY, it skips right over serializing my "FK_ENTITY_TABLE_NAME entity:
<PARENT_ENTITY>
(note: no FK_ENTITY_TABLE_NAME serialized here)
</PARENT_ENTITY>
Is there anything i can do to control the XmlIgnore attribute from being inserted in these generated files?
I'd suggest first off to fix your naming convention. Other than that make sure that you expose a get method for your DATA_ENTITY class so that it gets compiled into the generated code.
Also, why is your include for FK_ENTITY_TABLE_NAME but the entity class uses DATA_ENTITY? That seems strange to me. Is there any other relevant code you haven't included?
I want to have a field in my entity where the returned data comes from a class function in mydomainservice and not from the database.
The reason is that I want to generate an image URL (Silverlight bind) based rather loosely upon other fields in a table
How can I obtain that ?
The other two have mentioned a partial class. They are correct. Here's an example...
public partial class MyImage
{
public string CompleteUrl
{
get { return string.Format("http://{0}/{1}/{2}.png", Host, Folder, Filename); }
}
}
This would assume that you already have columns named "Host", "Folder", and "Filename" in your database, and those have already been mapped to the appropriate columns.
L2S generates partial classes for all of its implementations. You shouldn't be doing your own mapping. These partial classes allow you to create a new file (with ClassName.cs) that will allow you to extend the functionality of your domain objects.
You can extend your linq2sql generated class by making a partial class with the same name (in the same namespace) and putting the method in that file.
Declare a partial class with the same name as the entity class and in the same assembly. Declare your function/property as usual.