Well i want to know how many architecture approaches we can use in asp.net web application. i was asked about it. i told him that i use a appcode for dal and bal and the presentation layer. but he was not convince. basically i want to ask what web application architecture an asp.net web application guru would use keeping in mind the different metrics ( i am talking minus web services or any SOA thing)
Classic 2 tiers app
Is the one you described: You have the client (the browser) connecting to the server (can be configured as several servers) running an ASP app with your AppCode classes acceding the database in the local network (or same machine)
n-tiers app
You can use WCF to delived n-tiers app where the client connect to the server and the server connect to WCF services running on the same server or in several other servers
Note: This is the short story and the naming is subject to debate.
Related
I'm currently in the middle of a large ASP.NET application with many WCF services. Currently in IIS, all these services are listed under one application called Services.
I'm concerned that with more being added to our servers all the time and the uptake of our application increases, this is probably not the best way to manage things. Currently the VS project has a "web service host web application", which contains all the .svc files to be hosted. The advantage of having it all in one is the obvious use of the web.config for all services. The disadvantage is that if we need to do an update or deal with a critical issue, all our services are brought down at once, rather than those few that we know the problem is located.
I'm wondering if it is possible to keep this "host web application", but split the application into different "sub-applications" using separate Application Pools and allow VS to publish to individual services. I don't know if splitting it into folders under the "host web application" and hosting these as individual applications will work.
Or is the only way to have lots of host applications to run in separate application pools?
TL;DR; Should I split our application with all services into 5-6 applications with a few services?
I'm pretty new in developing pc and mobile applications that need to work with the same database.
Maybe this isn't really a question but I would be happy to get some advice from you.
I have now a vs project written in C# with a Service-Based Database. I want to create a mobile app (can be only for android) and I want both the apps to use the same database.
What options do I have? Windows Azure isn't free and I can't spend any money on this so even a small trial (limitless) will work here.
I was thinking using Parse..
What do you recommend?
If I understand correctly I would suggest you create some backend service - web service or web api - that both application use which in turn uses the database.
This will allow you to re-use business logic across both applications, abstract the database away so that you can make database and logic changes without having to redeploy the applications and avoid the requirement to deploy database credentials with your applications (the backend service should employ some form of authentication)
A free-tier Azure mobile services can really help with the mobile device end but not necessarily on the PC (unless windows store app), but a free-tier Azure websites instance will happily host either web service or web api
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 am new to WCF and i am designing a project in which i want to run a crawler program (coded in c#) which crawlers some websites and it stores the crawled data in the tables of database (sql server db). I want that crawler runs repeatedly after 30 minutes and updated the database.
I want to then use the service on my hosted platform so that i can use the data from tables in web form (i.e. .aspx page)
Is it okay to use WCF for this purpose ?
Please suggest me how to move on ?
Thanks
Windows Communication Foundation (WCF) is responsible for communication between 2 points with different channel technology. you will use WCF if you want to send/receive some data between two point regardless channel technology (TCP/UDP/NetPipe/MSMQ , ...)
But you first need to design you crawler application which is configured to fetch data from your target web sites, then you need to design a schedular application using
http://quartznet.sourceforge.net/
to run your crawlers.
after running and storing your web pages you can use WCF if you need to do replication or synchronization with center server but it is optional
You could use a WCF service to do this but I would go for another setup:
I'd build a Windows application that is scheduled to run every 30 minutes by the Windows Task Scheduler. A simple console application might be fine.
I'd use a Web application (possibly ASP MVC) to query the database.
As you can see there is no need to use WCF at all.
An exception can/must be made when the server is not yours but you are using a hosting provider who doesn't allow you to schedule a Windows task. In that case you might want to run the crawling process by hand through the web application and have it repeat itself after 30 minutes.
Some hosting providers do allow the scheduling of tasks but in a different way so it might be worth to investigate.
I have a C# application that needs to always be running. I originally planned on making this a windows service but I now have a requirement to make the application host a web admin console.
I haven't played with IIS in quite a few years so my question is this:
What would you recommend I use?
I've thought about making a windows service and embedding a web server such as Cassini but so far I'm not very happy with the open source web servers I've looked at.
Can IIS handle this? Do people use it for this type of scenario, and if so how?
This sounds like a job for two separate projects.
One is the original Windows Service. Windows Services are well suited for what you're doing.
The second is the Web Project that will be used to administer the Windows Service. This is the part that runs in IIS.
It depends on what you mean by always running. An ASP.NET web application deployed in IIS could very well be unloaded by the web server if there aren't any requests for certain amount of time killing all background threads. So if you want an ever running background thread it would be better suited to use a Windows Service. As far as the web admin is concerned, well, here you don't have much choice: ASP.NET in IIS. In order to do something useful those two applications should be able to find a common language to talk. So you could use a database to store the results into which could be used by both applications.
IIS will run your app on first request, not on server boot. So you will still need to run a service to ensure your app is always running.
You can use IIS as a webserver for your web admin part, and link your ASP.net app with your service by means of a configuration database (easy) or webservices (a little more tricky).
Windows and Web services are two very different creatures. A web service will expose external methods that you can implement against an application, while a windows service is an entity within itself. If you're planning on using this service on a timed interval to perform an operation, a Windows service would be the right way to go. If you use a web service, you will need to invoke the method you wish to run from a secondary application.
If you need to queue commands against your windows service, you could always create a database that was accessible by both your website and your windows service. This way you could send commands and query data between the two. Placing a web service in to serve as an intermidary between the two may be overkill.