I have using self tracking entities and I do the following:
1.- I create a new entity
2.- I modify one of its properties, for example entityName="Dummy"
After the modification, the state of the entity is still unchanged, so when I do the applychanges it does anything.
I try to set its state to modified, and then it saves the changes in the database. But in this way, I have a problem, because if I am not wrong, STE implement the INotifyPropertyChanged interface, so when I modify a property, is notify and this is a feature that I would like to have.
I am wrong? Perhaps when I change a property the entity it would not be changed its state.
Thanks.
Daimroc.
EDIT: this problem also occurs when I get the entities when I consume a WCF service which send me the results of a query to a database using EF 4.0.
EDIT2: I found my error.
The problems is that I have a dll project in which I have the tt file and the Self tracking entities.
I have a WCF service that has a reference to this project. This Service use a repository that use EF to access to the database.
I have a self host application in which I host the WCF service. This application has not a reference to the dll with the STE.
I use svcutil to create the service.cs.
I have the client, in which I add the service.cs. How the service.cs has the classes of my dll project with the STE. But there is a problem, this classes does not have all of this classes. I mean that for example has the ChangeTracker property, but their has not the MarkAs method and others.
So if I edit the service.cs to change the namespace in which is declared my classes and add a reference to the project with the STE classes, the I have access to all methods and also works as I expected.
So the problem is in the "STE classes" of my service, not in the STE classes of my dll project.
Why when I generate the service.cs don't generate the "complete classes"? This makes me add a reference to my dll project with the STE and edit the service.cs to delete the code with its STE classes that don't work as I expect. is there any way to have in the service.cs file the "good STE classes"?
Thanks.
Daimroc.
The problem is that I have a WCF service that I host in an WPF application. I run the self host application and with svcutil I create the Service.cs.
I add this Service.cs in my client application. In this Service.cs exists my
Your description is too confusing.
STEs make tight coupling between you service and the client. The only correct way to use STEs is to place them to separate assembly and share this assembly between client and service. When you create service reference for the client application with svcutil.exe you can use reference parameter to specify that assembly for type resolution instead of creating new non STEs types (VS UI for adding service reference offers similar configuration).
Related
My web application in ASP.NET uses Angular as its frontend. For database and API, I made 3 projects in the solution. API, BOL and Entity Framework.
BOL has all the POCO classes.
Entity Framework has the DbContext class and the connection string to the SQL Server database. It also has the reference to BOL. All the repositories with insert, update, delete and get methods for every entity are there too.
API has the API controllers with crud functionality which call the methods from the Entity Framework project. It has a reference to Entity Framework project.
But when I try to call a method from Entity Framework on the instance of the respective repository, it asks to add reference to BOL. But it should not use BOL as that ruins the purpose of the Entity Framework project
it depends how you are using the POCO classes.
if the EF project uses POCO classes to return results and your API calls methods inside the EF project then you will need a reference to BOL because otherwise the API project doesn't know how to deal with the results.
The fact that both the EF and the API project have references to BOL is not an issue, it's exactly as it should be, since both use these models and that's why you separated the models in the first place. You want them to be shared.
So bottom line, if the EF projects takes input or returns data using the BOL classes then you need to add a reference to that project in your API project.
Now, for the second issue with the connection string having to be in the API project, that will have to stay that way. The reason is because of how the framework works.
You have a main project and you reference a class library. When you compile the solution, the EF dll get built and copied over to the API project. At that point it will use the settings of the API project, not its own. This is why connection string needs to be in the API project as well. Looks inside the APIs bin folder and you'll see what I mean.
I created a WCF service in charge of exposing my database's data since I don't want the database to be directly accessed by my application (for security reasons) and i need to be able to share data with third-party applications.
My solution is structured this way: WPF application -> WCFService library -> DataAccessLayer library. (Arrows define assembly dependencies 'depends on')
To implement the WCF service I considered to simply return detached EntityFramework objects from the service BUT it forces the main application to have a dependency on the DataAccessLayer library.
The only way i can get around that is generating POCO objects and use them to send them over the wire, but now i have to map values back and forth EntityFramework.
At the moment i'm generating POCOs dynamically via a T4 template and I'm using AutoMapper to map values back and forth EntityFramework.
The Wcf service will just have to implement the repository pattern to expose data.
Is this a good solution? Are there any other option?
Is there any shortcoming i should be aware of?
Depending on your constraints, I would have to agree with this solution.
I created an almost identical solution, although our motivations were slightly different. Our client was Delphi Win32, and at the time didn't have good support for JSON, so we had to use SOAP.
The client also didn't support nullable primitives, so the POCOs removed all unsupported types, and performed other changes to ensure interoperability, then we used Automapper custom mappings to handle the two way conversions.
All the WCF services (contracts and implementations) where also generated by T4 templates, using a generic repository. With T4 templates, I was able to generate a separate WCF service per table for CRUD operations, and then manually created WCF services that were business specific.
Finally, I was also able to used T4 templates to generate the Delphi repositories that interacted with the SOAP services.
Or
You could just as easily move the POCOs (and code generation) to a separate project, change your DataAccessLayer library to reference the POCOs library and only contain the Db context made up of DbSets of your POCOs, and Data access logic but no entities (which are now POCOs). Your clients will not need to have a dependency on the DataAccessLayer library.
So... a good solution, depending on your constraints.
What I'd LIKE to do is manipulate EF to support plugins that access a shared database. So the database would contain all of the tables for the main application plus all of the tables required for each plugin. As the application doesn't know anything about the plugin data structures, it cannot be responsible for their management. The plugins are solely responsible, and create the tables themselves. However, the plugins know about the host application and its data structures, so ideally should be able to reference them and even inherit from them, resulting in a database that is extensible yet able to implement optimized patterns.
In EF, this translates to a HostContext that contains the DbSets appropriate for the Host. Each Plugin, I thought, should have a PluginContext that inherits from HostContext that contains the DbSets needed by the plugin. The entity classes included in PluginContext would then be able to reference HostContext entities, and/or inherit from those entities, and EF would be able to resolve the table mapping and relationships.
I'm using EF6. When I attempt the above and try to list the single entity I've included in the PluginContext, an exception is thrown complaining that the entity doesn't exist. Sure enough, no matching table has been created.
Is what I'm attempting to do supported by EF? If so, what am I doing wrong?
As I mentioned here: EF6 Empty Model target string
I began this effort using Rowan Miller's example here: http://romiller.com/2013/02/15/extending-and-customizing-code-first-models-part-2-of-2/
In the end, I abandoned that approach, for a few reasons: 1) I couldn't get it to work (I can't remember exactly why but I do suspect it was related to differences in EF since the article was written), and 2) I didn't like the need to write manual migrations.
I ended up with PluginContexts that inherit from HostContext, as I had hoped, and am able to reference and even inherit from host entities. This has restrictions in its use though:
My plugin logic is completely self contained. I have no need for the host application to manipulate or create plugin entities. Therefore, I am not trying to get the system to subsitute any plugin entities for host entities. If construction of a particular entity subclass is required, then a plugin method must be provided for that and an inheritence hiearchy will be utilized.
Migrations can be built even on the plugin context as per normal. However, that migration may easily include migration code from the Host Context. So I have to remember to look for and remove these instructions. This is typically very straightforward and I believe is much less effort than building the equivalent from scratch.
If there is any change to the Host Context then this must be reflected in every Plugin Context. Basically, this means anytime a new migration is created to reflect changes in Host Context, migrations must be created for each plugin as well, even though that migration may be empty (it isn't really - the critical part here is updating the Model in the latest MigrationHistory record to reflect the Plugin model that has been changed because of the inherited Host model).
This approach is being used to extend an in-house application with in-house plugins, and so may not be as easy to adopt in other scenarios which Rowan's solution is probably better suited.
I am looking for some best practice advice with regards to building a self contained service, that is a DLL with all of the domain logic and data layer. I would like to use an off the self CMS, such as orchard, then talk to the service to carry out CRUD operations. The service should have it's own IOC, and ORM, in this case I am using Ninject and Entity Framework. In this design I will have a separate database than the CMS, and can port it to other CMS systems when required.
The CMS should start the service and pass it a connection string or file name. If I use orchard it has different ORM, and IOC frameworks, so this leads me to wanting to keep Ninject and Entity Framework inside the service.
I have setup an experiment where the DbConext and domain are in the service DLL, and I call it from a console app. This only works if I have entity framework referenced in the console application, even though I don't use it in that dll. Here is the error message when EF is not referenced by the console app.
No Entity Framework provider found for 'System.Data.SqlClient' ADO.NET provider.
Why is this and how best to solve my design problem?
If your library (DLL) depends on Entity Framework, it's perfectly normal that you need to reference both in your application (whether it's console, web or whatever else). You always need to reference all dependencies.
Wiring your custom library with Orchard would be fairy simple. The only thing you'd need to do on Orchard side would be to register the services coming from your library with Autofac, in order to have them available for dependency injection. This post describes a similar scenario to yours.
Please bear in mind that using multiple database connections is a bit troublesome in Orchard <= 1.6, because of the usage of TransactionScope - you need to run all your custom database code in a suppressed scope, otherwise you'd have transaction errors and/or MSDTC-related problems. It will be a non-issue since Orchard 1.7 which is going to arrive in about a week. I'd strongly recommend waiting for the new version. You can also fetch the pre-release code from 1.x branch.
I have an ASP.NET 4.0 website that has an Entity Data Model hooked up to WCF Data Service. When the Service and Model are in the same assembly everything works. Unfortunately, when I move the Model to another "shared" assembly (and change the namespace) the service compiles but throws a 500 error when launched in a browser. The reason I want to have the Model in a common assembly (lets call it RiaTest.Shared) is that I want share common validation code between the client and service (by checking "Reuse types in referenced assemblies" in the Advanced tab of the Add Service Reference dialog).
Anyway, I've spent a couple of hours on this to no avail so any help in the regard would be appreciated...
When you move the EF data model into its own assembly, you need to make sure to still have the EDM connection in your web.config where your WCF Data Service lives. Did you possibly remove that connection string??
I got the very same error after I referenced an EDM model in a separate assembly from a web application. Once I copied the EDM connection string from the model assembly to the web.config for the web application where my WCF Data Service lives, everything worked out just fine!