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.
Related
we can do CRUD operations using Entity framework but we can also do same CRUD operations using entity framework & Web Api.But why we need to use WEebApi.please give a real time Example..Try to tell answer without using it is light weight or to make restful services..
please differentiate between CRUD operation using entity framework and EF + webApi..what happen when we use one another.
Entity Framework is an object-relational mapper (O/RM) that helps with data access from DB.
It can be used to perform CRUD operations, execute Stored procedures, query views etc.
Web API is similar to web service. It is primarily used to communicate over HTTP which entity framework cannot do. Web API can receive requests over Http and call Data Access Layer (EF) to perform data access operations.
Hope it helps!!!
Entity Framework is an ORM. Assume you build a web application which functions on its own, has a UI and saves stuff to the db. In a simple scenario like this there is no point in trying to complicate things by adding an API into the mix, so your ORM is more than enough.
Now, imagine you have 2 applications, a web one and also a mobile app. They both take data and they both need to save that data to a database.
How do you achieve that without duplicating the work? This is when an API becomes needed.
You build an API, hide the database operations behind it and now both your web app and mobile can talk to one common layer and use the same data. This a very common scenario, if multiple apps need to share the same data.
There are of course other use cases, sometimes an entire business is focusing on providing data to clients and don't want to worry too much about how they're going to do it. They would provide an API, document the standards, secure their API and let clients use it as they need to.
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..
So we are focusing on developing a enterprise web application that utilized DDD patterns with CQRS+ES. We have a pretty good handle on that from the enterprise level. Now when we want to open up our backend services to native mobile devices using Xamarin and portable class libraries how does this come together? Do we change our domain projects in each of our bounded context to be a PCL project type? What do we do with the MVVM side of things for instance in Windows Store App, Windows Phone app? Since we are pulling from a Web API service do we pull in the PCL bounded context library or do we make a subset domain model and a separate PCL library for our native client MVVM patterns?
Right now we are leaning towards leaving the original DDD projects as class libraries and just creating a separate portable class library for our MVVM code. We will probably use file linking to link back into the domain projects to get the models so that we always have the latest set of POCO objects and any DTO objects we want to use on the client. Any one else have any thoughts or ideas on this? I really don't see a lot of discussions around this DDD+PCL combination.
I have done a lot of thinking about this and what i did to put Xamarin in my current architecture with DDD approach was:
Put your Domain Entities in a PCL project and use it to reference in all projects that you need, such as Xamarin.Forms, Xamarin.Android, Xamarin.iOS, ASP.NET, WCF, etc.
Your Domain Services can be in a normal class library that will be used for the Application layer. The application layer will be used by the Presentation projects such as ASP.NET MVC.
In the Distributed Services layer you're going to expose your services for Xamarin or other apps to communicate with your application. You can use ASP.NET Web Api or WCF with REST. This layer will also use the application layer respecting the DDD concepts.
The xamarin projects go in the presentation layer but do not use application layer. Here you will write your services for Xamarin to connect to your Distributed Services Layer through the internet. If you need offline sync you can also put that in here. Here you're going to reference your Domain Entities Project and have all your entities with their business rules.
This way you have your domain and business rules shared with all your solution and respecting DDD concepts and role separation.
We have a web2py application that we want to connect to an EmberJS client. The idea is to use the responsive capabilities of EmberJS to keep the client updated writing minimal code.
We have (REST) primitives which are in charge of creating / updating the underlying datastore (CouchDB). These primitives are sometimes complex and covering corner cases, involving the creation of several documents, connecting them, validating configuration parameters, ... This is implemented in the backend. We would like to avoid duplicating the full modelling of the data in our EmberJS application, and avoid duplicating the logic implemented by those primitives.
I have some questions:
does it make sense in EmberJS to just model a subset of the data in the documents? We would just create models for the small amount of properties that the user is able to interact with. The client would not see the full CouchDB documents, just the data necessary for display / interaction.
is it possible to connect EmberJS to a REST interface, without having to fully model the underlying data in the database?
does it make sense in EmberJS to just model a subset of the data in the documents?
Yes. There is no need to create ember models for objects/properties that user will not need to interact with.
is it possible to connect EmberJS to a REST interface, without having to fully model the underlying data in the database?
Definitely that is possible, it's a fairly common use case. The best way to get started is by building a small MVP that works with just couple of models. Once you've got that wired up it will be easy to add more domain objects.
The tricky part (especially at first) will be mapping your rest endpoints to the ember-data REST adapter. The adapter will work out-of-box with some REST endpoints - see the REST Adapter - but connecting a CouchDB datastore will probably require some customization. The tools for this are still evolving, have a look at ember-data integration tests to see what is available.
We're investigating the iPhone Enterprise Developer Program as a way to develop and distribute in-house apps. Since our backends are all Windows, SQL server and Oracle databases, we have to find out a way to make our data available for the coming in-house apps.
As far as I know that Core Data is mainly based on SQLite as persistent store. I am not sure if there are any APIs available in iPhone SDK for SQL server or Oracle database? Another possibility, or very attractive strategy, is to build our own web-based REST services as CRUD gateway to our databases.
Personally, I prefer to integrate in-house apps with our ASP.NET based web services. I am not sure if this is possible. Are there any examples or documentations about this strategy?
an interesting option is to expose your data from your server using asp.net OData then use this project to generate a client in objective-C to consume your OData service.
As far as I am aware there are no approved API's to access a server based database. The way we do it in our organisation is pretty much the way you are suggesting. In some instances we are using SOAP but typically we just use a custom JSON or XML web service to access the data.
With regards to ASP.NET are you talking about making native iPhone Apps with ASP.NET or getting a native iPhone App to talk to an ASP.NET web service? If its the first then have a look at monotouch (don't know much about it), if its the later then this shouldn't cause issues. Just use NSURLConnection and deal with the resource structure on the App (be it JSON or XML).
The added advantage of using a web service rather than a straight database connection is that you get encryption for free using https.
Hope that helps
There's a product called SUP (Sybase Unwired Platform), it provides a framework to handle access to databases but has the advantage that there doesn't need to be an online access all the time, it stores persistent data locally and then can sync up with the host database using messaging.