We have a regular .Net4 desktop application built using WPF that exposes a handful of methods via WCF as Net.tcp and also WSHTTP as a rest interface for some simple remote control and remote querying. This is so we can provide some easy 'dashboards' that keep track of what each of the applications is doing around an organisation. We have used MVVM patterns wherever possible with future expansion in mind.
We now need to build a web application for users to do some remote work. Most of this work will be done by the web interface itself directly accessing the SQL database and other resources and rendering HTML back to the end user.
We also want the users of this web application to be able view these dashboards for certain specified desktops, at which point we need to then have the Web application query the desktop applications for the answers.
In due course it's likely that we will expand this further to expose REST or SignalR based or similar to support a Xamarin based set of apps.
My current theory is that we will build this web application using ASP.Net and host on IIS and whenever the user needs to access a resource that requires connecting to the desktops we spin up a WCF connection to the REST services running on it, send the query, process the result and return it onwards to the user.
Is this the best way to go about it, or is there some sort of native web service "proxy" that we can utilise to transparently forward the request from the website user onto the desktop?
Any and all advice would be greatly appreciated!
Related
I've been studying Xamarin.Forms with goal of building cross-platform mobile app in VisualStudio2015. I've got a perfectly acceptable public facing web site but native app(s) are what the boss thinks we need.
The current web app hosted on IIS 7.5 uses a separate project(DLL) for database access to an on-premises SQL Server 2008 instance. This VStudio project exposes domain objects to the calling ASP.NET webforms by executing various stored procedures using System.Data.SqlClient.
I know building the mobile native app itself with Xamarin.Forms is one part of the challenge but I am asking here for clarification about how to approach the database requirements:
Do I need to create some sort of web service that provides the same CRUD functions required by my current web site?
Xamarin documentation lists several options for consuming web services and the more I search and read about data access I conclude that a callable web service of some type is going to be required for my eventual native mobile app.
Is this assumption correct?
Yes. You generally want a webservice layer brokering requests between your mobile app (or any remote client) and your DB server. If you already have all your crud operations in a separate library that is utilized by your website, then a webservice would just be another set of endpoints that rely on the same CRUD library.
I need advise on the architecture of my new application. In the environment I work in, we normally create Win based apps and these compose a UI layer, Business Layer, WCF Service Layer, and Data Access Layer. These are on a 3 tier architecture with Services Server, Database Server and clients machines accessing the application via Citrix on an Application Server. I just created a web aplpication and my admin has suggested this should be hosted on a separate web server, my question is, is there a need for my web application to use a WCF Service Layer, since it can be hosted on the same application server? Basically, do websites need to use wcf/service layers and what are the benefits?
1.
Read this:
http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic
My advice:
At the least, you should use WCF, and use "named pipes". You can deploy both the Host (WCF) and the Client (Asp.Net website) on the same machine.
The Asp.Net website will be the "client" and access the service.
Then, if you ever want to horizontally scale, all you have to do is change the .config settings to use a different protocol besides named-pipes.
Aka, you'll have the "logical separation", even if you deploy both on the same physical machine(s).
They (websites, any project) don't "need" to do anything.
You can write inline sql code behind buttons on webforms if you want.
But its not maintainable. And its not scalable. And it is probably foolish.
But putting in the time to SOA a mid to large sized application is worth the effort in the beginning, IMHO.
This is a question without a concrete possible answer, do you need a wcf? well that depends on the requirements and the architecture you want to put in place.
based on the small context you provide maybe you can get some the following benefits
WCF Provide state for operations
Fast processing (binary serialization)
WCF are more likely 'to be testable' than legacy asmx web services
You can access the same backend you built for your desktop applications
regarding if than can be accessed from the same server, the short answer is yes (obviously you need to measure your server capabilities)
I've done some app's that doesn't use a wcf at all, and other that use it for certain operations you can take a look to this SO answer to get a good example where a wcf could be a good candidate in an app.
I'm creating an iPhone app that has a DB in PostgreSql. I want to create web services that connect to the database and fetch the data in and out, like for example , I want to create a web service for the login screen of my iPhone app that would connect to the PostgreSql database and authenticate the user.
How do I go about with the web services part..?
Looks like this question is destined to be closed, but before it is locked, I'll try to provide some direction. You can use any of your listed technologies to publish a web service. ASP.NET is my technology of most comfort, so might I recommend looking at using a simple web application with an exposed Page method, and using Npgsql as the database interface.
Using a simple page method isn't the most robust solution, but it will serve simple needs and requires very little specialized knowledge nor a WCF implementation, which can be daunting for some.
I am in the planning phases of building a new ASP.NET website. The website is really a transactional web application where the users will log in and perform basic CRUD data operations. For right now this website will be accessible through a traditional desktop browser and a mobile browser. For the mobile browser we will build a separate scaled down version of the site.
In the future we may decide to create native mobile applications for Android or iOS devices also.
So the question I have is what is the best way to design the system to easily support that? Here is what I am thinking. I am thinking of building out 3 tiers to the site. The back end will be the database - SQL Server 2008. We will use stored procedures for all data access. The middle tier will be a web services tier. This tier will be built using RESTful web services and will contain all of the business logic. These web services will provide access to the database. The front end will be built using ASP.NET. The front end will only contain presentation logic. These tiers will actually be deployed on physically separate servers.
Then I am thinking that when we decide to build a native Android or iOS app that we could build those apps to simply call the same RESTful web services that the main site is calling.
Does this seem like a reasonable approach? The only thing I can think of is that the way we are building it right now the web services would be behind the firewall and would not be accessible to the outside world. When we want to support a native mobile app then we would need to make the web services accessible to the outside world.
Any thoughts? Does this seem like a good approach for building a high availability, high usage web app that needs to support native mobile apps in the future?
Thanks,
Corey
I'm with Rober Harvey there. With ASP.NET MVC you can make the presentation site in no time, use as Models your web service; with the link that he gave you, set the site for mobile browsing, and use the web services for the mobile apps when you build them.
For me it looks like a good plan. Regarding the web services being public, you can protect yourself by implementing API keys in the web service, so only your apps can use it.
I have a .NET 2.0 WinForms application that was developed using the Composite Application Block and Smart Client Software Factory.
I'm considering the development of a module that would contain a browser control that would access the ASP.NET website using credentials established when the user logged into the WinForms client.
My goal is to use this strategy to transition all of the modules that are currently in the client to ASP.NET and retire the 'smart' client. Security for the WinForms client is currently implemented using the ASP.NET Membership functionality.
Is this possible? Sensible?
Yes, you can. Make a SmartPart that hosts the WebBrowser control, add some buttons for forward and backward navigation, and a url textbox; then point the WebBrowser control at your web application's URL.
It is sensible. We used CAB/SCSF to create an application we called "The Integrated Desktop". This application serves as the platform for all internal apps for the company; everything is integrated into this one desktop application. We added a foundational module, basically a beefy version of what I described in the above paragraph, to facilitate web browsing since a few pre-existing apps were web-based and our users wanted access to those at the same place they were doing all their other work. One cool thing was the use of the WebBrowser's ObjectForScripting property that allowed for somewhat seamless integration between the desktop app and the web app being hosted inside.
What are your requirements?
You would choose a web app over a smart client mainly
if you have to reach people that
are not on the Windows platform or
you have a need for a
zero-install app
By having your app users having to access the web app via the smart client (browser-control) you would be missing (1) and (2). In my opinion it would defeat its purpose.