As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I want to do an application that use a database and can show the information in datagrids, execute commands with buttons and so on. I want to do it inside the lan and outside the lan.
I think that i have two options. Create a desktop application that use wcf to connect with the service to access to the database. The second option is create an aso application, so I can access to the database with any browser through internet.
Are the two options a good solution? What are the pros and cons of wcf and pros and cons of asp.net?
When to use asp.net and when wcf?
When you only have one client and your only need is to access it via LAN and internet then developing an ASP.NET application is less overhead. This because you don’t need to setup an extra service that you need to configure and secure. On the other hand creating a good UI for an ASP.NET application can be much harder than just a WinForm of WPF application (depending on your UI-needs).
But…. What if you’re planning new clients in the future? Maybe a (native) mobile app or another (windows/web) client for a different group of users with different needs? Then a web service give you some advantages…
For example you want to make a new Windows Phone application (in addiction to your web application) for some CRUD operations.
When you write all the database logic and business rules in you web application you can’t use it directly in you Windows Phone. Okay you can maybe you can use the assembly if it is compatible with that .NET framework profile. But what if you want to create an Android application without using Xamarin or something similar. Than you can’t use the assembly’s from you web application and you need to rewrite your logic again… When you had a web service (for example a REST web service) you can call the service for all the database and (shared) business logic. And you don’t need to care about if its working the correct way. As you probably can see maintainability can also be an advantage of a web service because all the logic is centralized in the service.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a Windows desktop application (developed with C# using .NET 2.0 framework) that I would like to connect to a rails web app. The scenario would ideally work as follows:
User runs the Windows desktop app and generates some results. The desktop application then uploads the results to a database that the Rails web app can manipulate and do interesting this with (for instance, make pretty graphs).
My experience with .NET is limited but I have a fairly strong background in RoR. I am currently tripped up on which type of database to use as well as how to make the two applications manipulate the same database. Any suggestions?
You can use any database that's available to you. .NET or ROR will not limit your options.
You can have the rails app poll the database for said data (Not so good). OR you could develop a web service and have the desktop application call it to trigger the data manipulation.
Web services on rails.
How to consume webservices in C# winforms
More on consuming web services in C# winforms
"I am currently tripped up on which type of database to use"
Name your poison! :) You can talk to practically every database on the planet from both .NET and Ruby/RoR, including:
Relational databases like SQL Server, DB2, Oracle, MySql, ProgreSQL, etc.
Document-databases like MongoDB, CouchDB, RavenDB, etc.
Other NOSQL key value stores including Cassandra, Dynamo, Riak, Redis, Memcache, Azure Table Storage, etc.
Pick one that meets your needs and go for it.
"how to allow communication between the two applications"
I am not quite sure what you mean by this, but I'll assume that you mean that at some point, after uploading its data, your app should open a web page displaying a nice graph of the data? If so, this is trivial and requires no direct integration between your .NET app and your RoR site other than your .NET app spawning an instance of a web browser, and asking it to open a given web page:
var process = new Process();
process.StartInfo.FileName = "iexplore";
process.StartInfo.Arguments = #"http:\\myreportgenerator.com?customerid=1234";
process.Start();
If you want your .NET app to be able to ask your RoR site to do specific things, then consider adding a REST web services API to your RoR site.
Go one step further and you could actually eliminate all DB code from your .NET app and just have it ask for and send data to your RoR site via REST (JSON/XML over HTTP) calls, performing all DB IO internally.
The database can be anything you want that both .NET and RoR can communicate with. I'm not a RoR expert, but .NET can talk to just about any db you want.
The communication between the apps happens via the database. You insert / manipulate the data via the C# app, then read the data and process it with the RoR app. There really should be no direct (app to app) communication between the two apps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I work at a small startup as a Data Scientist, and I'm looking for ways to make my analysis a bit more visible/useful to the organization. I'd like to be able to put up a simple web service which allows internal users to run my scripts remotely. They should be able to input a few parameters via a very simple UI, and they should have the option to have the results appear in the browser window (after a possibly long wait), or have them emailed. Results may be a few pdf figures, and they may be Excel spreadsheets (maybe more exotic in the future, but this is it for now).
The scripts are going to be all in Python, which will handle the analysis.
So, I'd like to know what the pros and cons are of using C#/WCF vs. something like Django or Python. I have significant experience in C# working in the Client-side code base here, but I have much less experience with WCF. All of my analysis work is done in Python (and R, to a lesser extent). The main goal is to not take all of my time building a fancy web service/UI---the front end just has to be friendly enough to not intimidate the marketing people. I don't have to worry about encryption, the server will be behind our firewall. I'm pretty platform agnostic, but I think the servers are all Windows based, if this helps.
Thanks in advance.
For extra credit, how does your answer change if some of my scripts are in F#?
You might consider using the Django web framework. You could set up a small app with your python scripts as different views. https://www.djangoproject.com/
And if you don't want to put that much effort into creating a friendly UI you could use twitter bootstrap. http://twitter.github.com/bootstrap/
Then just run the app internally to gather and display data either via HTTP GETs or via e-mail.
edit: I'm sorry I did not read carefully "pros and cons are of using C#/WCF vs. something like Django". I recently made a Django app and it was fairly straight forward.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm about to build a fairly complex web application from the bottom up, and I want to do it the right way with appropriate design patterns (which I haven't always used in the past) and the latest .Net technologies.
My ambition is to start out with a web application, but make it possible for future mobile apps, and third-party application development and plug-ins.
This leads me to my main conundrum: For the web site (which I'm going to build using the MVC pattern) should I use WCF to expose my data model as an API, or should I simply reference my data through a dll (or a separate project in the web application solution)?
Let me back it up and give you some of my other design thoughts, so you know what I'm trying to do, and please come with input and suggestions if any of this seem like the wrong approach:
I want to build my data model using EF and the code-first approach, using design patterns such as Unit of work and Repositories.
I want to expose my data model (1) through an API using WCF.
I want to build a web application using TDD and MVC, where I get my data from my data model (1).
So, given the above, it seems like an additional hassle to have the web application use the WCF API when I can easily access the data model elsewise, simply by referencing it in my web application. In addition, the latter seems easier since I would have immediate access to all the objects in my data model. I can't see how that would be possible using web services? The reason I would want to use a WCF API is that I've heard so much praise for the idea of only exposing your data through an API, no exceptions, in order to truly be able to develop for multiple platforms. What other reasons are there? Can I use anything but Http messages for the WCF? Can I expose objects, and, if so, how?
I feel like a lot of the answers I'm seeking can be found on-line, but I've spent a lot of time looking at the separate pieces of the puzzle and still have a hard time connecting them all to fit together. I hope you guys can help, and that this is a question that can benefit others as well.
As I said, I want to do this the right way, so your input (at any stage of the design phase) is very appreciated.
Thanks!
I'd say build a data API using the new WebAPI framework. That way, anything that can consume a RESTful interface via HTTP can connect to it: http://www.asp.net/web-api
Also, you can set up your project so your Data Model is referenced from a separate project so you don't necessarily have to go over the network in your main web application. The WebAPI project can be separate, but use the common model to make sure things are consistent
Take a look at WCF Data Services (DataService) and WCF RIA Services (DomainService)....which can expose your Entity Model as a service.
http://jack.ukleja.com/wcf-data-services-vs-wcf-ria-services/
This guide can help you decide on how to architect your tiers/layers.
http://apparchguide.codeplex.com/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am going to develop a client side application such a way that my client should able to receive fixed line calls through a computer and the application which is running on client's machine able to save the caller's number to a remote database.
Is there any application currently available for this? What are the requirements should I have before begin the project?
You will probably have to setup a PBX system in your client computer if you are wishing to connect phone line to the computer. You'll have to buy a Terminal and input a SIM to it. Or you could buy a SIP trunk from a Service provider and you'll able to take calls via the Internet.
If you are connecting with Java you'll have to use Asterisk PBX API and some configurations are necessary inside the PBX system. For logging calls to the remote database would be easier since Asterisk can be configured to store Calls to a MYSQL database.
As for more customization of this process would require a remote database and manual logging.
If you are going to use the Asterisk API you will find it quite helpful since you can take calls directly using it. But if it's for a simple use you can go ahead and install a Softphone - something like X-Lite or Linphone.
You can refer this tutorial for more use of Asterisk Java.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have a web portal and the web portal has web services API.
Which solution would be best and why?
Should I....
1) Run the web portal and the web portal API on the same server or
2) Run the web portal and the web portal API on separate servers
It's all a matter of trading off different forces, there just can't be the same answer for everybody.
Here's a few things to consider:
Having the UI (portal) and it's dependent services on the same box makes for a very clear set of dependencies, when diagnosing problems you've got just one place to look. You can scale by adding more such boxes, each being self-contained. Clarity has a lot of operational value.
But, it's likely that the portal or the services will have different resource requirements, hence you are scaling (say) the portal when the services are not using much resource. Hence you have more copies of something portal or service than you strictly need. This may have considerable costs. Examples:
Licence costs. Suppose you have 10 copies of portal but really only needed 5, then that's 5 licences wasted.
Memory consumption. Suppose there's a fixed overhead in getting the services (or portal) up irrespective of load demands (think caching or database connections) then you are paying that cost for the un-needed instances
Back-end costs. Your services may connect to enterprise systems, eg a database. Each connection costs resources on the back-end. If you have un-needed instances you pay needless costs.
3.Platform tuning. You may need to tune the platform differently for your portal and the services. This issue is more noticable when considering whether to co-locate the database too.