I have one dll containing my entire mvc app running on iis7 server. Should I instead have compiled controllers and business logic into separate dll's? Furthermore, should I install the non controller dll's in a separate server and if so do I configure a new virtual directory to the remote server?
What is the typical practice here? Thanks
I guess that depends on your business needs, but in general I am a fan of modularity. We have our Model shared between multiple sites so it is in its own DLL and the controllers etc. for each site are generally in another (for each site) and additional add-ons in their own as well.
Compiling into one DLL would probably get you a performance increase, but you would be hurt when it comes to upgrading individual modules.
Related
We are developing intranet base solution in ASP.NET MVC. It will be deployed across client's own internal network hence respective employee of client can use it.
As it is IIS based intranet application, one can easily copy files and configure IIS on other server. So what are the different solution available to prevent this.
Thank you in advance.
Generally when you are publishing the ASP.NET MVC web app, you can publish the version in dlls.
So Instead of creating a single Web App, you can create a new dll file where you are going to compile all the Models of the App and save it in a dll).
Then coming back to your original solution you will add the reference to this dll so no logic can be taken of your solution.
I have web application that are using multiple clients.
I should create one copy of application for all clients or every client should have its own copy.
I am using Asp.net MVC and SQLServer.
What you suggest.
Creating seperate projects per client will be troublesome to maintain while a single project for all clients could be difficult to customize. It is a fine line and your needs will dictate how you build your solution.
One of my more recent projects where we do SAS (Software as a Service) we were able to build our MVC application using a plugin architecture so that each client COULD have their own DLL deployed to the BIN that would enable customizations for just that client (to the Views, Assets or even the Controllers). We are able to leverage a single code base and have many clients, most without customizations and some with minor to heavy customizations.
Every client has a unique URL for their "portal" and most often they have private domains, so http://app.mycompany.com or http://mycompanyapp.com and some are even hosted on our own site, http://hostingcompany.com/client/.
By building an application that can determine what client it is based on the URL we were able to handle all of these cases with ease. When we deploy we have a single code base (deployed just ONCE to a single folder) and all of the sites use that same code deployment.
We run a web farm where we have many .NET Web Servers and have load balancing setup and the sites all have ping pages that our load balancers interact with to determine their health.
Like I said, your needs will determine what the best solution for you is.
Nick , what about database should we use one database every client or should have separate database for each client in my scenario our application is more database centric so there are lot of changes done for each client as per there business roles .
What way makes the most sense? I have a ASP.NET app... and maybe a Silverlight app in the future.. I want both to talk to web services..
At first, I like have the WCF project be by it self for the seperation..
But then I thought.. What is the point since I can just as easily have a 'WEBSERVICES' folder that contains all the .svc files and code in the EXISTING website project. ... Atleast that way.. deploying to a remote host will be a little easier since everything is in one project..
any other considerations ?
Why not have:
your WCF service and data contracts in a Contracts assembly
your WCF service implementations in a Services assembly
reference those two assemblies from your web site or web app
put the *.svc files into a WebServices directory
That way, you have
clean and nicely organized separation of concerns
the deployment files (*.svc) are in your web site / web app as you want
you can still extend / use your WCF code in other ways (e.g. self-hosting) later on without much fuss
Two things to consider:
Security - are your services only going to be used by your application, or do they have the potential to be used anywhere else (after all they are services). If so, you will be granting access to your application in order to grant access to your web services, or at least tweaking the access to that specific folder, which might lead to security breaches.
Deployment - If you do changes on your service that doesn't break the contract, in order to deploy the changes you will have to deploy the whole application.
I would prefer to go with the approach that Marc suggested (e.g. have an assembly for contracts, one for the service implementation) and have the webservice hosted as its own application and reference it from the ASP.NET app. This way, you have proper separation of concerns and can maintain both separately.
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change
I have a Visual Studio solution containing a web site project plus a bunch of supporting projects (domain model, data access, etc).
I want to expose an API to the same underlying data, via urls under the same domain, so I developed a WCF/REST project to do this (which has dependencies on the same set of domain/data access projects).
Now I'm wondering what the pros and cons are of having the WCF service in a separate solution, deployed under a virtual IIS path, compared with just putting the WCF project into the original website solution.
Are there good reasons why I would want to go one way or the other? I'm not too experienced with IIS deployments.
IF you ever want to self-host the service instead of hosting it inside IIS, or if you ever want to share the service interface as an assembly for some reason, it will probably be easier to have it in a separate assembly.
I would recommend one assembly for the service interface(s) (including data contracts and such), one for the service implementation, and another (if needed) for a self-host (e.g. Windows NT service or command-line app). That's the cleanest separation and there's no real reason not to go that way, IMHO.
Marc