I am a web guy and I was just hired by a company that does only desktop apps (WCF/WPF) to help them start moving to web apps, using asp mvc.
Their current architecture uses 3 different servers, UI on one, service on one and DB on one, apparently to keep the UI and DB very separate.
So with moving to web apps, I am wondering how mimic that architecture. They are mostly internal apps, so I really dont see a reason to involve 3 different servers. If we do Web API apps with MVC front end, can the API and front end be on separate servers? I have never done web api stuff, so not sure of the structure.
I am used to a repoitory pattern (UI > ViewModel > Controller > Repository > ORM/EF > DB ) with a repository between the controller and and DB. How would web api be better?
Related
I have a standard nteir setup :-
Web server -> App server -> DB server
I have an MVC 5 web application sitting on the web server with controllers calling a WCF services project sitting on the App server. WCF services project uses EF6 to marshal data on the DB server.
I am wondering if WCF is overkill? Is there is an easier way to achieve this same architecture? I am thinking I should have gone with Web API on the app server and then just call the web API from the controllers with the HTTPClient?
Or, I could even just use a plain MVC project on the App server returning JSONResults to the MVC controller on the web server?
It depends...
You have to understand what are the benefits of each set up. This is not exhaustive, just a quick brain dump. This should give you some hints to look further as in the wild world there might be many more reasons for choosing one or another solution.
Why WCF. Are you going to have different clients to your backend ? You need some entreprisy security between clients and you backend ? With WCF you could configure Http, TCP endpoints, set message or transport security and a lot more. It could be needed for example if your doing an intranet application and you would like not only to have your UI (MVC application) but other systems going to it. If this is not needed WCF seems overkill here.
Web Api is also agreat choice if you would like to built more REST oriented api, enabling content-negotiation for different clients (different media-types). Building REST is not about issuing JSON, it's much more and this would be too long to explain it here. If your client is not only your MVC app, but you could have a need for a api for other mobile devices, OAuth authentication and the so, this could be a good way to do.
Plain MVC app would also fit if you don't have any special needs, go for it. No overhead needed. Keep It Simple And Stupid.
I hope this helps
I would not change this.
WCF is a good choice for communication between Web Tier and App Tier. I would never put my App Tier exposed to outside world, so if there is any communication to my app from outside world, it would be through Web tier only and if there is a need to support multiple clients, I would create a WebAPI on web tier and expose that.
I would keep App tier only available to Organization internal and with WCF I would have flexibility to write service code and contracts which can then be exposed over various bindings (transport, security, etc.).If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF is indeed a good choice.
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
I am launching my startup and i need to make a critical architecture choice.
I will provide a SAAS web application for my clients, they have different specific needs but the main purpose of the program is the same, automatically generating documents and pdf.
Technincally i choose ASP.NET MVC, WebAPI, EF Code First. Now I have a working proof of concept with only one project (1 db, 1 asp.net mvc client, 1 asp.net webapi, 1service layer + 1 repository)
I will have one database for every client (easier to maintain, scale ...)
One WebFront for each client with personalized html/css templates and of course specific data/menu
Only one WebApi service exposing all services for each client,
For example /api/client1/, /api/client2/ with almost the same api calls but not the same data returned.
For each client a service layer (Class library dll) that stores business logic, data acess, POCO/DTO.
Each Webfront shares reference to specific service DTO/POCO.
I need of course my solution to scale horizontally, not vertically.
So is it a good choice?
Do you have any recommendation/better solution ?
Can I put All this in the same visual project ?
I really would like to have the service layer(business) in only one project, and with good Object Oriented approach I can serve all my clients with common needs shared between all of them and specific one in derived objects.
Thanks for help
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I have a .NET v4 application consisting of a web application (ASP.NET MVC2) and several web services (WCF). During development I have deployed the app to IIS 7.5 using /app1/ for web application and /app1/services/serviceXX.svc for web services...However, for production deployment I would like to find out if it would be better to deploy these apps into separate web sites and host each from root context.
So here are some of the scenarios, I am thinking of and was wondering if someone can share some pros and cons of each...
Scenario 1 (app per web site)
Deploy each app to a seaparate Web Site under IIS 7.5 ad use root context (/). I can then assign separate app pools for each site.
For example:
http://app1.domain.com/ <-- ASP.NET MVC2 app #1
http://app1svc.domain.com/ <-- WCF services related to app #1
http://app2.domain.com/ <-- ASP.NET MVC2 app #2
http://app2svc.domain.com/ <-- WCF services related to app #2
...
Scenario 2 (web app per web site, all services for all apps in one web site)
In this scenario, each web app is deployed just like in scenario 1 but all web services for all apps are deployed in single web site of iis 7.5.
I am guessing, advantage in this case is that only 1 web site has to have WCF bindings
For example:
http://app1.domain.com/ <-- ASP.NET MVC2 app #1
http://app2.domain.com/ <-- ASP.NET MVC2 app #2
http://services.domain.com/app1/ <-- WCF services related to app #1
http://services.domain.com/app2/ <-- WCF services related to app #2
...
Scenario 3 ( one IIS web site with sub-context for each app)
In this scenario there is only 1 IIS web site and each application is deployed in sub-context (this is what I use during development).
This approach (seems?) simple and easier to administer than other 2 but I am not sure...
For example:
http://apps.domain.com/app1/ <-- ASP.NET MVC2 app #1
http://apps.domain.com/app1/services/svc1/ <-- WCF service #1 related to app #1
http://apps.domain.com/app1/services/svc2/ <-- WCF service #2 related to app #1
http://apps.domain.com/app2/ <-- ASP.NET MVC2 app #2
http://apps.domain.com/app2/services/svc1/ <-- WCF service #1 related to app #2
http://apps.domain.com/app2/services/svc2/ <-- WCF service #2 related to app #2
...
I am thinking that Scenario #1, although a bit more involved, is the most flexible as I can controll the bindings, limits, and other properties which are only available on a web site level.
What do others think?
Option 1 is the most flexible in some ways, yes. If you have any issues where any single app and it's web service needs more resources, it would be very easy to do so since multiple apps are not tied together on any single URL. It's easiest, IMO, to keep every app in its own app pool with this option.
Option 2 may be good; you could scale the entire 'services architecture' out for the collective needs of all the apps, as opposed to one or another. But that can be bad as well; if you have a small number of the apps whose services are getting higher use (as opposed to it being somewhat more 'level' in distribution), it may make more sense to be able to scale up only those services which need it individually. But honestly, I'm not sure how valuable that is.
Option 3, IMO, is the best option if you expect that all the individual apps might need to scale up together; That is, you don't expect to have a very small number of the individual apps that need considerably more resources than the rest. But even if you do, say, have just one that is much busier than the rest, this would still enable you to scale the entire app up. But with an extreme mismatch between needs of the separate apps, it might not work out so well.
I think ultimately it may really come down to what will be easier for you to manage, though. Will creating new sites or new virtual dirs/apps fit better with your expected growth?