We had a requirement to build a ASP.NET 3.5 web application using web forms, WCF, ADO.NET and SQL Server. The users would connect via Internet.
Recently we understood that it is possible that users would often remain disconnected and would have Internet access intermittently.
I need to understand if we can create occasionally connected web application using asp.net 3.5 - what all technologies/features we need to use? Is MS Sync Framework the answer to the problem - is it a viable option to use with web application?
Is windows application the right approach instead of web applications - where the business logic would be run at the client itself, using local SQL Express editions with data then been synced up with Enterprise SQL server at server end when connection is established using replication and/or MS Sync framework. In that case is there a need to use WCF?
Does Silverlight applications help in this context -building paritally connected web apps?
Really appreciate if you can give pointers to how to go about this task of creating .net partially connected apps (not mobile apps)?
It looks to me as if you'll need to store your client data locally when not connected.
If you use wcf you can determine what type of protocol to use according to connectivity without affecting your main code e.g. tcp/ip for LAN, http for internet and msmq for storing up data when disconnected.
If data for transfer is stored up using msmq, as soon as a connection is remade then the data will be passed to your main server.
If you write your wcf, or communications code to run as a service (assuming windows functionality here) then it is up to you whether to retain the asp code or write a new windows app.
edit
Setup MSMQ at both ends, its part of windows setup and can be installed on a client machine, just the same as IIS is, it's on the installation disk but not installed by default.
I wouldn't use it to get web pages, have those available on the local machine, but instead use it to queue up data that MUST get back to the server. Your data access layer should be separated from your GUI layer anyway. I assume that your using the MVC pattern or similar.
I don't know what your application is requried to do but here is the example that I've worked on.
A mobile user who visits clients. He has a replicated copy of a company product database on his laptop. When he visits client sites he may not be able to connect to his company server, but still wants to place client orders. This he does using his laptop based application and database. Order data is queued up in MSMQ on the laptop.
As soon as he is able to connect to his company server MSMQ automatically sends the order data. The server has queued up MSMQ messages of changes to pricing and stock etc. that took place whilst he was disconnected. These are now received and the local database is updated.
The choice of TCP/IP, HTTP or MSMQ all happens seemlessly to the main application, the WCF code copes with the choice.
From what I know, you have two options:
Use Gears (abandoned) or Web Storage to store and sync local data, combined with heavily javascripted web pages that can detect loss of connection and work against the local data store.
Use the Sync Framework with a rich client (WinForms, WPF or possibly Silverlight OOB if it gets supported). The Sync Framework does not require a local installation of a database, instead it uses SQL Server Compact, which is simply a local file.
At this stage using Sync franework with probably rich client seems to be better option. Thanks a lot Guys for taking your time out and trying to answer my queries. I will let you know the technologies used after i manage to deploy the app!
Related
I'm working on a project and I need to connect to MS Access Database. The problem is that I'm using a pretty new platform , I'm using Visual Studio 2015 Xamarin and I'm developing to android with c# (thought this platform).
I already have a project with this Database using aspx and i need to connect the android application to this Database .
I could not find any answer for it , probably cause it's new .
Thanks for helping.
The problem is not related only to Xamarin or MS Access.
Everytime you want to use the same database in different applications (in your case a website and mobile apps), it is better to create a new layer (WCF Service or REST API) in order to access the same database on the server. This is more flexible and would be the right thing in your case.
Without moving the architecture to the next Level, you will always have such problems when mixing old and new technologies together.
If you just want to finish this quickly for school and use the database only on the device, then there is no way to use the MS Access database with xamarin. I recommend using SQL lite for this and there are lots of examples for that:
https://developer.xamarin.com/recipes/android/data/databases/sqlite/
It not clear if the database is to run “local” on the android, or you just wishing to connect to some web service that holds the database?
If you needing a local database to run 100% stand-alone on the Android device, then Access is not supported. Your best bet for a local database would thus be SQLite.
Perhaps you don’t need nor want a local data store. In this case if the Access database is on the server, then you would be forced to write some kind of web service to “interact” with your Android software and the web server (this would not be a "general" interface to the database, but a set of web services that you expose on the web site - this assumes you thus have control and are able to write software and implement a web service on the web site. So in this case some kind of “direct” connection to the Access database is not possible.
You could again certainly DIRECTLY connect to a server based database like SQL server – but this would assume the web hosting allows external ODBC connections to the database (often they don’t allow this, but some do).
So not clear is if you need a local database running on the Android that can THEN connect to some web or server based system, or you simply want the android to connect via the internet to some database hosted on some server and the Android device does not have a local database at all.
Regardless of the location of MSAccess, you cannot "connect" to a non server database like Access. So the question remains as to "where" you want this database to be used, and ALSO if you need a local data store on the Android device or not.
I am building an application that needs to connect to a server to send and retrieve data constantly.
at first i was going to use mysql, by mysql is far from what i want. using this would force users to connect to the database constantly.
CAN C# silverlight connect to a server and send a message?
here is an example to something in C# console, VERY similar to what i am trying to achieve
https://www.youtube.com/watch?v=9kcrTKj7Jpk
Any documentation would also be helpful.
To be more specific my server will be written with C# console, but i want my c# silverlight to send the message.
Yes.
CAN C# silverlight connect to a server and send a message?
Traditionally, the way that Silverlight has connected to a server to send a message is with WCF services. This still works well, but the other option is REST.
What you will need to do is write a layer (or use an ORM like Entity Framework) to persist data from whichever database platform you choose (MySQL or otherwise). Then you will need to write REST, or WCF services on top of this. You will then need to consume the services from your Silverlight application.
There are many articles on this if you Google. Here is one of the ones that comes up instantly:
http://www.dotnetcurry.com/ShowArticle.aspx?ID=228
One thing you must consider with Silverlight, is that by default, Silverlight will only talk to the server that the Xap package is hosted on. So, if you need the Silverlight app to talk to a different server, you will need to set up and expose a clientaccesspolixy.xml from the server where the WCF/REST services are hosted. This is a stupid limitation that Microsoft made a big mistake on in the first place. Here is an article about it:
https://msdn.microsoft.com/fr-fr/library/cc197955(v=vs.95).aspx
I am working out the nitty gritty of a potential server / many-client project and it's in a realm I haven't been before. Disregarding the scale of the project for a moment and assuming this ever goes ahead....
My current idea is that the server should be a fat server with a thin rich client on each workstation, built in C# .NET and probably using WinForms for the user interface, and distributed via ClickOnce for easy and compliant software updating.
Database <-> Server (business logic) <-> Rich Thin Client
Instead of a fat client:
Database <-> Client
I am looking into WCF for the server. Is this advisable for a client-server architecture with the following usage case?
Anywhere between 10 and 100 receptionists and practitioners using the client (company growth would increase this)
Windows 7 and up being primary workstation operating system
Minimal data traffic desirable
Potential for large data to be stored alongside the database in some manner (patient images, video and such)
Is it wise for the server to be performing business logic as much as possible and only sending information and results and doing the basics on the client (validation etc)? It seems logical to me.
Does anyone have some good information on beginning such a big project?
I believe the current software being used is actually a fat client with a direct MSSQL connection.
Not only this, it is also non-distributed and each clinic has it's own separate database causing many problems with data integrity and collation for reporting and such.
This is perfectly valid plan for your architecture. WCF will do fine. If you need a tutorial on authentication sharing between the web application that authenticates users and the ClickOnce module run from within the application, I wrote one once:
http://www.wiktorzychla.com/2008/02/clickonce-webservice-and-shared-forms.html
This was written years ago and while I show how to share authentication between the ClickOnce and ASMX web service, sometime later I wrote another tutorial on sharing the authentication between a Silverlight module and a WCF service.
http://www.wiktorzychla.com/2010/04/aspnet-forms-authentication-sharing-for.html
Combining these two will give you ClickOnce + WCF authentication sharing.
I've got a question regarding the pros and cons of using a database vs. a flat file in a windows mobile application.
We're developing a mobile application running on Windows Mobile 6.5 and using C#/.NET Compact Framework 3.5.
The mobile component is used in an inventory system to do receiving of deliveries. These data are then sent to the application server using a web service via Wi-Fi.
Now, we need to implement a backup plan. What we agreed so far is when then the mobile is unable to send the data to the server, it has to persist it locally and then send it at a later time. It can either be sent using the mobile or the mobile can be docked/connected to a PC via usb which will pull the data out and the PC can send it to the server.
My question: which is better to use in this scenario? Deploying an SQL Server Compact or writing the data to a flat file (xml, binary etc)
I'd like to get opinions on the pros and cons of each method keeping in mind not only the technical aspects but also the development work involved.
Thanks!
My personal experience with this scenario is to use SQL CE to do Merge Replication instead of a web
service for some very good reasons:
Your application becomes easier to develop because you read/write directly to a database and let the CE engine do the merging. (Linq to Sql etc)
You can manually control merge conflicts at the server or client. And this is already built, you don't have to build it yourself.
There is no backup necessary because your data on the CE device is already in a database.
Data can be cached locally as needed and filtered by device or user (meaning only the data needed by the device/user can be the replicated to the device.)
Although this does require more SQL knowledge, it is solid technology that works, and doesn't have to be re-written, tested and debugged continously.
If you are locked into using a web-service, then using SQL CE seems like overkill to me. I would simply duplicate what a database does and write transactions to a file (xml/json/binary) and then use those as needed (running them against the web-service when in wi-fi range or having a service running on a machine that pulls the files off the mobile device and onto the local PC or server and running those transactions).
I am building a system which is made up of 2 application
ASP.Net Website where jobs will be created for engineers to visit data held in central database
Windows Forms Application running on Laptop where jobs will be synced from central database then a form is completed and data sent back to the central database.
What will be the best way to transfer the data, the laptops will be remote and may be on a slow connection.
I will be using SQL Server 2008, Entity Framework, .Net 4
I have looked at the Microsoft Sync Framework but unsure if this will do whats required, also thought about having a web service where the windows form client can pull and push data to.
I have had bad experiences with MSMQ so what to avoid this.
How would you approach this?
Take a look at merge replication for SQL Server. This would allow your laptop users to make changes to the data they've received while offline and later sync back to the central database.
I believe MS Sync framework is designed to handle just this problem. While you can use MSMQ, you'd be writing most of the logic to do the syncing yourself. Sync framework should give you a better abstraction and take care of most of the details.