ASP.NET WEB API Data Access Layer with Stored procedures - asp.net-web-api

I am very new to the MVC frame work and ASP.NET WEB API
I have been Building Web Application using ASP.NET AJAX with n-tier architecture with data as Stored Procedure Only for quite some time.
We are trying to upgrade one of our Products to develop using HTML5 ASP.NET WEB API and We would like to keep our DAL and stored Procedures intact and add a service Layer using ASP.NET WEB API or WCF Data Services on top of the DAL and HTML5 Presentation layer will hit the service layer for the data.
can you suggest if this is a possible scenario where we want to keep the database stored Procedures and DAL intact?
As I have noticed the support for Stored Procedures in EF5 needs a lot more maturity to support some of our stored Procedures with multi table datasets I know there are workarounds on this. I have seen EF 6 Alpha Specifications and I am excited about the features.
Does any one have a link to a tutorial or a sample of ASP.NET WEB API Service layer on top of a Data Access Layer? OR can you make some suggestions or point me to right direction please
If I have to make a wild guess on how I want to implement a solution for our current problem. I would say.
Present DAL gives us Dataset and wrapper for DataTable in the dataset to Convert to IQueryable and use them in ServiceLayer skip the whole EF workarounds.
thanks in advance

In reality you could to this. You could place your service logic into Web API, however, I wouldn't do this. I would rather add one more layer of abstraction in order to keep the API as lightweight and as simple as possible. According to your scenario you have something like this:
Back-end DB Server with Stored Procedures
Data Access Layer component for working with number 1, back-end DB.
Now you want to build API on top of 2. My suggestion to you would be to add Service layer (aka Business Logic layer) where you would put additional logic like calculations, if necessary additional validation, messaging services, etc.
And then on top of the service layer I would add Web API. So at the end your layering could be something like this:
Back-end DB Server with Stored Procedures
Data Access Layer component for working with number 1, back-end DB.
Service Layer (Business Logic)
ASP.NET Web API
HTML5 Client
The idea behind this is that sometime again in the future, when you need to add additional features to your product, you would do it in the service layer. Don't go on and add complexity to your Web API. Think about maintenance, testing and future expansion.

Related

Are there any concerns with using Snowflake as the data repository for a web API?

Are there any concerns with using Snowflake as the data repository for a web API from an enterprise architecture perspective?
I think the question to be asked is how are you going to use the data. It is not clear what you mean by web API data repository. If you are talking about the API interaction data, then Snowflake is not the right choice for that. You should look for a transactional data store for such use cases. However, from that data , if you want to derive insights and analytics you can ingest the transactional data to Snowflake and build your analytics layer on top of it. But the question will be why would you like to do that, most of the API products have that analytics engine already built in their product.

How to change the configuration to build as single deployment with multi-database?

I came a cross this boilerplate just couple of weeks ago and it's the coincidence that I was working on designing Multi-tenant Saas Architecture using .Net Core Framework, EFCore as ORM, SPA(Angular)as presentation layer, and OData Api but then I found this boilerplate is exactly what I am looking for. I have one question how to set-up configuration on this sample Event Saas app to make it as Single Deployment with multi-database?
I have noted there is appsetting.json where subdomains are stored and in each entity for example Event is inherited from IMustHaveTenant that means each entity should have TenantId means this setup is suitable for single deployment with single database (database filter is automatically applied by aspboilerplate) but I am looking to make it single deployment with multiple database (Each database per tenant). It will be great if you just give me some clues.
Note: This is what I am talking about.
Thank you.

ASP.Net or Node.js in the following situation

Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.

How do I validate ViewModels across an ASP.NET MVC and a Windows Phone Project?

I want to create an application that has both an ASP.NET MVC 3 web client and a Windows Phone 7 phone client. The application data is stored in SQL Server and needs to be accessed from both clients.
Given that scenario, I have two questions:
I want to reuse the view models I use in the (existing) MVC application in my phone app and validate these using FluentValidation. Am I supposed to create a new class library called ViewModels and reference it in both client projects, or is there a better way?
Would it be appropriate to create a Web Service that both clients talk to? Or is it better to access the data via the MVC web project?
How would an appropriate solution structure for that scenario look like?
Am I supposed to create a new class library called ViewModels and reference it in both client projects, or is there a better way?
Yes. Except you can't. Or well, you can, but you need two different project types for this. I'll recommend using shortcuts in one of the projects.
a "Windows Phone Class Library" isn't accessable from ASP.NET, and visa-versa.
Would it be appropriate to create a Web Service that both clients talk to?
Yes, very appropriate
Or is it better to access the data via the MVC web project?
You could host the web-service in your web-project. But a seperate service is easier to maintain, if you have the ability to host it.
With RestSharp you could easily integrate it with ASP.NET MVC.
You can create a library that contains the viewmodels and is used by both client projects if it is a Portable Class Library. (They were created for just this scenario.)
I know FluentValidation has support for WP7 but I'm not sure of the differences in that version or if you'll need to do anything special to work with a PCL.

What is the equivalent of LINQ-to-SQL for Silverlight?

I have a WPF application that uses LINQ-to-SQL on a local .MDF file. This solution is simple, easy, and effective, i.e. I set up my model once, then read/write data anywhere via LINQ:
using (var db = Datasource.GetContext())
{
oldItem = (from i in db.Infos
where i.Id == TheId
select i).SingleOrDefault();
CreateForm(db, FormBase, oldItem, Button_Save);
}
What is the dead-simple equivalent of this for Silverlight apps?
Searching I find an explosion of terms:
WCF RIA Services, WCF Data Services (ADO.NET Data Services, Astoria), Data Services Toolkit
.NET RIA Services
OData(Dallas)
GData
REST, REST-based, REST-like, REST-inspired
XML, JSON, RDF+XML
web services, SOA
cloud-based services, Azure, SQL Azure, Azure Services Platform
All I want to do is this:
create an .mdf file
use some LINQ-to-SQL-like tool to generate a web-enabled (REST?) data layer etc.
ftp the .mdf file and classes up to my ASP.NET web hosting service
write silverlight clients that read and write to this data source with LINQ
Concentrate on learning RIA Data Services, or WCF Data Services. It converts your LINQ queries inside Silverlight to REST requests, and saves you from writing some of the infrastructure code. The whole idea is that your SL app communicates only to web services, you don't have access to physical DB, like when you're using some ORM (L2S). In SL, your are inside browser's sandbox, which prevents you from accessing file system, including db files.
Other approach is to write web service and expose data through it (GetArticleByID), and then you consume that services from Silverlight. Then you use LINQ to iterate on fetched, loaded data.
Here's what to do -
Create a Silverlight app using Visual Studio. You will get two projects, one with the Silverlight XAML, and the other a web application to host it.
In the web application, add your DBML (Linq-2-SQL) file. Configure as normal
In the web application, add a Silverlight enabled WCF service
In the WCF service, define some methods that access the L2S data context
In the Silverlight project, go to add Service Reference, hit "discover" and add the WCF service in
Instantiate the service, and access your methods
Sounds a little complex, but pretty straight forward in practice.
Not possible. Silverlight cannot access databases directly. Some sort of web service layer is required in between. I think WCF and RIA Services are the most widely used.
I would strongly recommend that you clear an hour in your schedule and just watch this video:-
net-ria-services-intro
In fact clear 2 hours and work along side the video building your own copy of the app being built.
If you want to develop a regular LOB (Line Of Business) Application, then you should follow the approach using a web service interface to your database. The RIA services or WCF data service is the current RAD (Rapid Application Development) technology by Microsoft to make this task easier.
If you're talking about a special scenario you need: Silverlight 4 when running out of browser can talk to COM servers on windows now. Talking to databases is described in this vast blog post: Cutting Edge Silverlight 4 Com Features.
If you're looking for a way to manipulate database-like files, you may take a look at the csharp-sqlite project. I think it compiles for Silverlight without much ado (quick and dirty proof of concept here: Proof of Concept csharp-sqlite in Silverlight). With it you could create and manipulate a database file in the user's isolated file storage in a regular Silverlight application and then upload it to wherever you desire.

Resources