I've programmed a lot in asp.net mvc web applications. Now I want to write cross-platform mobile applications with cordova for the frontend and azure for the backend.
I am in doubt whether to use azure mobile services or WebAPI, because I want the power and freedom of WebAPI, but the convenience of azure mobile services. I do not understand concepts such as authentication, push notifications, etc.
My main goal is to focus on the application logic, frontend and backend with a significant weight of that logic in the backend. For this I have great doubts.
1st. I see both good mechanisms in AMS and WebAPI for external authentication, but not to manage your own authentication. What is the best way to manage your own authentication? Is Azure Active Directory solution?
2nd My intention is to create a well-defined API methods that return the exact data (json), rather than a rest api queryable (odata).
Wich is te best for this, WebAPI or AMS?
3rd I have experience with SQL Server, its relationships and Entity framework, but I do not care to learn and use NoSQL technologies, which is better? (However, I'm not comfortable with I can not use many to many relationships in NoSql).
Thank you very much.
there is not a real general answer for that, so take these as advices.
At first, keep in mind that AMS and WebApi are not so far. An AMS project IS a WebApi project with some helpers inside to make you comfortable working with related services (push notification, table entities), but you will lose a bit of control on your application.
The choice depends on your needs
Azure Active Directory IS a solution, but there are a lot more. You can use your preferred framework. AMS has got a pretty integrated login with most known social network and azure active directory as well, and is very easy to set up.
I'd suggest AMS. It will be easier to setup and mantain.
AMS is just WebApi castrated. To get all these services easier for you, you cannot for example
Customize startup of your application
Use a dependency injection framework
Run background tasks
And other stuff like that.
Hope it helps!
Related
I am planning to build this side project that helps me learn better about backend development, authentication and socket programming etc.
The idea is to build a chat application where users are mapped based on their interests and they can then talk about that topic.
To maintain the authenticity of the user I thought of adding an Authentication (Basically Phone Auth) Service. Even though there are various prebuilt services like Twilio, Firebase etc. I really want to learn the core of how they were built so that I could build that service on my own based on My Needs.
Thanks in advance
I know this sound strange, but please bear with me. We have a legacy desktop app (DataFlex), and we are developing a new web app. Both apps share the same business logic. We are in the process of moving the business logic to a centralized project that is exposed as an asp.net-core web api, to be used both by the desktop app and the web app.
So far, we have been able to access the new business logic project from the legacy desktop app via COM, but because maintaining interfaces and DataFlex wrapper classes is a pain, we are hoping to find an easier way.
We could access the business logic using the web api via http. But many users are still only using the desktop app, and setting up web servers for all of them is not something that can be done anytime soon. So we want to call the asp.net-core project in a way that resembles the way a web app does it, passing method calls as strings (JSON?)
Is this feasible? If so, how?
When catering for multiple .NET Client Applications - say - Web, Desktop and then throw in an Android app (Java), placing the business logic behind some WCF REST API services can make it easier and quicker to build applications, as there is no business logic to implement client side for each technology.
(I know that there will be a point of changing the UI to cater for new business logic, but the idea is the core of the system sits behind an API, not in the client application.)
Although RavenDB serves as the Storage Mechanism...
What is the general architectural advice of using RavenDB behind SOA services? Is it just your standard IDocumentStore/IDocumentSession behind the WCF instance and go from there?
Yes, you can just use it like that.
Note that RavenDB comes with clients for both .NET and Java.
I am developing a application that is using backbone.js for most of the front end logic and was thinking of using sqlite for storage, but i have run into a few complications with it and need to switch to another NoSQL database.
I see on ravendb's site that it was created in C# and you need a .net compiler. Most of the docs are for ASP MVC type application. I can not go this root because we are developing this as a tablet application with no microsoft based technologies on the client side ( because we want it to work with android and apple )
The server however will be .NET and so i figured this might be do able. Just wondering if this is worth pursuing and if anyone has had any experience using ravendb? Or should i go for mongodb?
It is possible to expose RavenDB directly to a JavaScript application, sure. But it's usually not recommended. The main reason is security, but there are many other reasons to have a middle-layer.
For example, you often need a server-side location to perform application logic. Not everything can be done in the database itself, and if you do it all in the application then you will probably send a lot more data to the app than it really needs. Over the internet, that could mean a slow app.
The route many people take, is to use ASP.Net WebAPI, or ServiceStack, or another similar framework. This gives you a way to expose REST endpoints that your JavaScript app can call. You can connect to RavenDB from there.
Also, you seem to have the misconception that if you used ASP.Net MVC on the server that you couldn't target Apple or Android. That's just false. Whether you use a SPA approach or a traditional approach, you are delivering standards-based content, such as HTML, CSS, JSON and JavaScript.
Yes, You can use it. Actually RavenDB's server is a RESTful web service, which means you can work with it with any kinds of HTTP clients. These clients should be able to issue standard HTTP verbs like GET, PUT, DELETE etc.
ASP MVC is server side. I still at a loss as to why you would want to expose your db to a clientside piece. It is completely worth doing in a server side piece, but do not expose something like a db directly to your client.
I have a web application in MVC 3 (3-tier with a Data Access Layer) that I'd like to extend to native iPhone and Android etc... as presentation devices.
Can I just use the same controllers with some modifications or is it better to organize the access logic into a WCF service?
What are you recommendations in terms of good scalability and performance?
For scalability, it would be better to have your business logic in a service that your UI (MVC site, iPhone app, android app) simply calls. I personally suggest using ServiceStack over WCF, as it simplifies your calls down to POCO objects. This will help for scalability, as well as maintenance as it separates your concerns much clearer (I suggest you read up on the SOLID principles). If you need to make changes to your UI, those changes will not affect your business logic (which would have caused your iPhone app to change possibly)
It all depends. You can certainly go the route Justin recommends. There's a lot of work in that, though.
MVC4 has WebAPI, which gives you RESTful services from within an MVC controller-like environment. This allows you to add a service layer to your MVC app with minimal effort.
For anything large scale, you should probably go with a full WCF implementation.
FYI, MVC4 is in beta, but there is a go-live license, and you can install WebAPI without installing MVC4, it's availble via nuget.