I have the following setup but am unable to finish building as I get an obscure error related to line 439 in file Blazor.MonoRuntime.targets (MSB3073).
Does this essentially mean that Entity Framework Core will in no way work with Blazor preview 6?
Details:
Asp.net Hosted Blazor
AspNetCore.Blazor (3.0.0-preview6.19307.2)
Microsoft.EntityFrameworkCore (3.0.0-preview6.19304.10)
Microsoft.EntityFrameworkCore.Design (3.0.0-preview6.19304.10)
Microsoft.EntityFrameworkCore.SqlServer (3.0.0-preview6.19304.10)
Resolved via a hack solution!
Somehow I was able to resolve everything and makes things run
end-to-end. I believe the big, critical thing was:
* Ensure that the Blazor client AND server projects do not directly reference Entity Framework
* Do not let the Blazor client reference (directly or indirectly) the project with the generated entities). To get access to the models, I
just create a duplicate of the generated entities (and removed the
"partial" from the classes that were generated)
Some clarification is needed here, right:
You cannot use Entity Framework on the Client project of Blazor. Entity Framework is a server technology.
You may use Entity Framework on the Server project of your application.
Communication between your Client side and Server hosting side is ordinarily done via Http calls (HttpClient service), but you may also employ SignleR.
To enable Http calls you should expose Http routing endpoints... This can be enabled by using Web Api with the required endpoints. Your Web Api exposed methods (Controllers' methods) can access the database directly (or indirectly if you define repositories, services, etc) via Entity Framework objects, and return the queried data to the calling methods (HttpClient methods).
Note that in my answer I particularly relate to Blazor Client-side apps, but it is mostly true with regards to Blazor server-side apps. I may just add here that in Blazor server-side apps you don't have to use Web Api since Blazor is executed on the server. In such a case, you can define a normal service to retrieve the data from the database, and pass it to the calling methods (no HttpClient involved here).
The Shared project intended to contain objects that can be used by both the front end and back end. This is the place where you can define your Model objects. As for instance, you can define an Employee class that can be used to retrieve the data and pass it to the Client as a list of Employee objects, and in the Client you can define a list of Employee objects that will store the retrieved data. In short, you don't have to define two types of objects, one appropriate to the server, and one appropriate to the client (say your client is an Angular app).
Hope this helps..
Related
At my job we're gradually replacing a monolithic legacy system with a microservices architecture. I've been tasked with writing an auth server using Asp.Net Core, Identity Server 4 and Entity Framework*. The legacy system already has auth and our deadline is approaching, so we're going to use the legacy system as a backend for the time being.
How can I set up Identity Server/Entity Framework to pull login info through the legacy system? So far, everything I've found involves adding a database like SQL server. Assume for the sake of argument I'm not able to pull data directly from the MySQL database that the legacy system uses, but it is easy to get the user data via a JSON API.
I have written a DbContext and an implementation of IProfileService which uses it, but I'm not sure how to actually pull the users in the DbContext, and when I try to sign in from a client I get this error:
No database provider has been configured for this DbContext. A provider can be configured by overriding the DbContext.OnConfiguring method or by using AddDbContext on the application service provider. If AddDbContext is used, then also ensure that your DbContext type accepts a DbContextOptions object in its constructor and passes it to the base constructor for DbContext.
However I haven't been able to find/figure out what to put in DbContext.OnConfiguring to set this up. I suppose I need to implement IServiceProvider somewhere, but can't find any details of how to do so.
*We're not married to these so suggestions for something more appropriate are welcome. We are using .Net Core.
The EF bit seems like a red herring here. If you're talking to an API in a legacy system then you won't use EF for that at all.
If using IdentityServer4 then it makes sense to use their EF implementations for the configuration and operational stores and then implement your sign in UI, IClaimsService etc using the API exposed by your existing system. To do that just create a simple client implementation that calls said API and accepts and returns whatever models you require.
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.
I have a project with a web api, a web app and Xamarin Apps. They all should use the same data model stored in a AspNetCore Library. I want to use EF Core for the database and I have a Db Managing project (also a AspNetCore Library) referencing EF Core containg the context and setup. The web api is the only project referencing this Db Managing project, because it handles all the database access. All other apps are contacting the web api for data interaction.
My problem: I want to use AspNetCore.Identity for my user management, but the Xamarin Apps cannot reference the data model, when its using AspNetCore.Identity. How can I solve this?
Your Xamarin code should be totally decoupled from server business logic and data access. Why would you reference AspNet Identity from Xamarin? Those are two completely different layers.
Your server Web API has to expose REST methods to handle authentication/authorization and other stuff so a client can consume them (web client, mobile client, desktop client, whatever).
Xamarin should consume those remote methods with a REST client, in the same fashion a javascript client would.
I understand from your question that you want to reuse business objects / models in your xamarin project just because they are written in C#. But if those objects have dependencies on asp.net identity, you can´t.
In that case you should map your business objects (BO) to data transfer objects (DTO) that web API will use to communicate with clients.
DTO´s are completely agnostic from any data access layer and should be simple POCO´s. They are meant to be serialized/deserialized to/from json/xml.
On the other hand, you don´t want to serialize user models "as is" through a web api because that implies sending sensitive data over the internet like user hashed passwords, etc. Your DTO´s should just have the fields needed in your client, and the mapping will do the rest.
I share a Data Transfer Object between an C# Azure Mobile Services server and client. I use the same class in both applications.
The TableController class used by Azure mobile services requires the DTO to inherit from 'EntityData', which in turn implements interface 'ITableData'.
ITable Data lives is part of reference:
Microsoft.WindowsAzure.Mobile.Service.Tables
I have not figured out how to include that reference without installing the entire server-side mobile services package in nuget:
WindowsAzureMobileServices.Backend
That includes OWIN, and many other references the client does not need. This is what I am doing currently. This works for a desktop application I am currently working on, but I think it will not work for universal apps and windows phone apps.
I also looked at microsoft's samples for mobile services, and there they use separate classes as DTOS for server and client.
Is it really the case that we have to write the same code twice?
No, but you could better make use of Shared Projects, and partial classes.
Your Shared Project will have common properties for the entities.
Other projects will reference this Shared one, and can add some other properties to shared entities, still using partial classes.
I have precise experience with AMS, so I know what you are meaning.
In my experience, is anyway not realistic to think to have exactly the same entity classes for client and server.
For instance, in so called Portable Class Libraries you can have a very small subset of framework, and references available.
Other than properties, you normally put attributes on POCO class files. On the client you may have some attributes that aren't available/meaningful for the server (e.g. SQLite attributes), or viceversa. You may can get stuck in this situation also with the shared projects approach I suggest, but it could be managed there with what so called preprocessor directives.
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.