We have a large MVC .NET website for a hospital; it has a Doctor Portal, and a Patient Portal. In essence it is two sites, with very little feature overlap. We outsourced the Doctor part to a Vendor and now we are creating the Patient part. I am recommending that we create two separate MVC projects since we are creating the Patient portal from scratch and don’t want the headache of integrating within the other code. Control, Route clashes etc. There are already 100 routes in the Global.asax for the doctor site.
The Director is somewhat technical and wants me to explain why I want to create another project. I simply don’t want the headache of having to work in other code, within the same view folder, and control folder. What are my options? Am I jumping the gun, and should just stick to the current project. Also the doctor site is live and we are adding the patient part. Does MVC/.NET offer a workaround for this?
This sounds like a good case for using MVC Areas - a feature added in MVC 2. Check out this MSDN article for more information.
From the article itself:
... However, some applications can have a
large number of controllers, and each
controller can be associated with
several views. For these types of
applications, the default ASP.NET MVC
project structure can become unwieldy.
To accommodate large projects, ASP.NET
MVC lets you partition Web
applications into smaller units that
are referred to as areas. Areas
provide a way to separate a large MVC
Web application into smaller
functional groupings. An area is
effectively an MVC structure inside an
application. An application could
contain several MVC structures
(areas).
One of the benefits you'd get by using two different projects is that if one part of your system falls, the other doesn't. If everything is chained together you might bring the whole thing down.
If they're on separate projects (separate servers,etc.) then your patient portal would survive; and as you say, the patient portal shares very little with the Doctor portal.
Related
I have a quite large ASP.NET project to work on, the front-end part(design).The code for it is allready written but given it has 80+ web pages I need to organize the files a bit so I can ease my work.
What would be some general pointers in organizing a allready written ASP.NET project?
P.S
The project has like 2 folders tops, everything else is in the main project folder.
Each application organization will depend on its complexity and business purpose being achieved. However, the more you are able to segregate functionality, the more manageable it will be for you.
Divide the functionality into business vs infrastructure.
The business one will get classified into different modules per workflow type involved. The infrastructure one will get classified into functional blocks like logging, security, database. There will be one admin section to manage users, map roles and permissions, check access logs etc.
We have a number of small ASP.NET MVC apps. All are basically a bunch of forms which capture data and store them in a SQL Server database, usually which are then loaded through to our datawarehouse and used for reporting.
We are looking to rewrite all the small applications and apply a level of consistency and good practice to each. All the applications are fairly similar and I think from a user perspective it would be better if they seemed to be part of the same large application so we were considering merging them together in some way as part of the re-write.
Our two currently preferred options seem to be:
Create a separate portal application which will be the users point of entry to the apps. This could have 'tiles' on the homepage, one for each of the apps (which would be registered in this parent app) and could link them through to all. In this scenario all the Apps would remain in different projects and be compiled/deployed independently. This seems to have the advantage of keeping the separate so we can make changes to an app and deploy without affecting the others. I could just pull common code out into a class library? One thing that annoys me about this is that the parent app must basically use hard coded links to link to each app.
I looked into using 'areas' in ASP.NET MVC and have all the small apps as different areas in one big project. This seems kindof cleaner in my head as they are all in one place, however it has the disadvantage of requiring the whole app deployed when any of the individual ones are changed, and I have a feeling we will run into trouble after adding a number of apps in to the mix.
We have a SharePoint installation and someone suggested creating the portal type app in SharePoint... This doesn't sound like the best idea to me but am willing to consider if anyone can point out advantages to this method.
Are there any recommendations on the architecture of this? Has anyone completed similar projects in the past and something worked well/not well?
We have 4 developers and we do not expect the apps to change too much once developed (except to fix potential bugs etc.). We will however plan to add new apps to the solution as time goes on.
Thank you
MVC Areas advantage would be allowing code sharing, by refactoring the repeated redundant parts of each app to use the same infrastructure code (security, logging, data access, etc.)
But it will also mean more conflicts when merging the code initially.
Deployment concerns can be mitigated with a continuous deployment tool (there are many in the market) or if you deploy to an Azure WebApp, then deployment slots can give you a zero down time deployment.
We have following two types of business connections: customers and suppliers.
Each of them have their own website which allows them to interact with us (b2b).
Now we are developing a plattform on that the suppliers (sellers) can create offers which are listed on the customers (buyers) site.
The design of the plattform for each site is identical and only differs in a few points depending on if it's an buyer or a seller. For example: On an offer-page only the buyer can buy.
To prevent double code I created a new website where the whole customer<->supplier shopping thing is handled.
We're thinking about to integrate the two parts of the shopping plattform in each of the designated webs (customer-web / supplier-web).
My problem is that I don't have any good idea how to prevent the code of the website from duplicating.
I had following ideas:
iFrame in each site with automatic login-share over tokens.
-> I don't like this idea because I don't like iFrames.
Compile the pages into dll's and refer the dll's in each web.
-> I have no idea if this is possible. I did not find anything pretty useful for this idea.
So my question is: Are there other/better ways to realise my demant? For me it's important to avoid double code. It also shouldn't be to much afford if possible (so reprogramming the pages into UserControls is no way for me since this is a lot of effort and it's hard to make changes).
I have a scenario that i have never come across and as such require help. I created an Visual Studio Web Application. The solution had two parts.
Project that holds all the UIs and
a Model that contain my c# code.
The objective was to achieve a 3 tier architecture. The model being the middle tier. The project is running and everything is awesome. NOW! This is my situation and I dont have an idea on how to approach it. I have to build another application, which basically is an extension of the first one. So how I went about starting this was to add another WEB Project to my currently solution. This had a lot of problem. When I deploy the project two web pages would load (one from each project). What i want is ONE webpage to load and base on your userId it will send you to the appropriate location. What I also saw was the second web project i added needed it's own users. How it should be is.. one set of users each having specific access to the application (which ever part). I need input on how to go about getting this done.
What I want is to debug 1 solution (with the 2 parts/projects). Base on userId he/she has access to a specific project but there is one user list that governs the entire solution and not two list, one for each project.
Is there a problem just adding pages to a directory in the existing web project? Normally, separate projects would be deployed as separate applications, not as merged into the same application. You can control access using web.config files in the "secured" directories
Another Architectural suggestion would be to create a Main web project that was sort of a wrapper if these applications are extensive enough and functionally dissimilar enough to warrant separate projects. This would be where your routing logic would take place and would provide simple stub directories for your paths (user-type 1 ... user-type n). Then you can create a project for each of your end paths and set some build actions that take the output of the sub projects and copy them to the output directories for the wrapper project, but this gets pretty complex.
I would still recommend keeping this as a single project if it is to be deployed as a single web application.
While it's possible to make this work as two separate systems, it's really a lot more headache than it's worth in most cases.
The question you should ask yourself is, is it really worth it to do this? What are you gaining from it?
This article explains how to do this:
http://support.microsoft.com/kb/307467
Another option is to create sub-sites, which is to add your additional project as a child. This is described here:
http://abhighag.blogspot.com/2012/03/separate-web-application-into-multiple.html
I have built and application in ASP.NET MVC, which started out orignally as a way to learn the technology. However, the application (and my knowledge of MVC) have progressed and I would like to use parts of the functionality I have created in other applications. Eg I would have 2 websites both wanting to use the same News Control (CRUD) model and controller methods, but with their own unique Views. I suppose my questions are:
1. Is this going against the principles of MVC?
2. What is the best way to achieve this?
3. Is there a "best practise" way to re-use my exisiting functionality?
Thanks in advance for any answers.
Depending on your exact requirements I'd recommend you take a look at Rob Ashton's series on multi-tenancy in ASP.Net MVC, and also the portable areas part of MVC Contrib.
You could setup a Visual Studio solution in which you would have a common class library project containing models, controllers and data access and two web applications containing only the views and CSS of the two sites both referencing the same controllers and models.
Hopefully most of your logic is already separated out, but you can also pull your controllers out to a separate assembly, I believe:
http://dotnetslackers.com/articles/aspnet/storing-asp-net-mvc-controllers-views-in-separate-assemblies.aspx
Reuse is a really central part to the concept of MVC. It's very common in production MVC sites to have a separate assembly (or assemblies) for the Model. It's somewhat less common (but still done) to do the same for Controllers. The S#harp architecture project (for example) uses a separate assembly for everything, leaving just views, content, and global.asax in the Web assembly. It's all good.
Another thing you might consider is the use of Areas, which are like mini-MVC apps that you can reference in your 'main' app. It's a great way to package reusable pieces like you describe.
Paul