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.
Related
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.
I work in a .net c# application which contains 2 solutions for client and server. In server side there are 80+ projects that have been used to separate following Architectural layers,
Infrastructure Layer
Integration Layer (External Systems)
Domain Layer
Repository Layer
Manager Layer
Service Layer
In addition, almost every layer has test project.Now, the build time of the solution takes 2 to 3 minutes, and many developers (including me :)) feel we need to tackle this problem.
Therefore,proposed solution was to reduce the number of projects by merging the projects.In my view, it is probably a good solution to minimize the build time and we could achieve what we want.
Proposed solution is that we merge our projects into 3 areas, such as one library for production code, one library for test code, and one for deployment projects (WCF host ,etc) and logically divided layers in same project by separating the namespaces.
However, my concerns are
Could these separation good for the maintainability ? providing that more that hundread of classes for each namespace appox.
If we have common functionality such as helpers, where are we put those ?
Is there any other way to layering the solution ?
I guess you should split your solutions in logical layers.
As part of where do you put the helpers. Make a solution for it, on one of the lowest levels.
EXAMPLE
Software for a farm. You'll need to keep track of your animals, vegetables. You need a module for feeding the animals and one for Selling the animals and vegetables to the consumer market.
This could be splitted in a the following solutions
Back-end
Sell Module: Everyting for selling your products
Buy Module: Buying seeds, food for your animals, other products, ...
Sheduler Module: Trigger events for sow seeds, harvesting, ...
Prediction Module: Predicting harvests quantity's by the weather, and market prices, ...
...
Each of these back-end modules, can have it's own Data Access Layer, DTO, WCF Services, ...
This solution will only contain Business Logic, Data Access, ... . And there can be multiple front-end solution connecting to these back-end solutions.
Front-end
ASP.NET MVC Application: Webshop for selling to a consumer
WPF Application: Approving sells
Other WPF Application: Buying things.
Mobile application: Getting the events to your phone or something.
(Another option is to connect 2 or more backend solutions into 1 front-end solution)
...
This is a BIG change for your project and this will have an impact. Make sure you think this true, if you wan't to change it.
Multiple solutions will INCREASE your overall Build Time and it's important to have a nightly build so every developer can always work on the latest binaries, without having to build all the solutions on his local machine.
Note you can still use your layers in the different solutions:
Infrastructure Layer
Integration Layer (External Systems)
Domain Layer
Repository Layer
Manager Layer
Service Layer
To make this work all together and don't get messed up with binaries. You can map a drive I.E. X: where you have a folder binaries, where you have a folder for each solution. where each solutions copy's the assemblies on the post build event. (Script this, so it works on every machine)
If you have a good network infrastucture, you can also copy it on a server. So when you build all solutions for example in TFS, it can copy it to a location all developers can access.
If you build in TFS make sure your build order is correct, first the lowest layer, last the highest layer.
But as you split up your solution, in solutions you'll probably don't need them in every solution.
I recently read an article about Onion Architecture, maybe you can have a look at that too. (It's specific for ASP.NET MVC).
You can also have a look into CQRS.
Why 80+ projects while you only have 6 layers in your application ?
You might answer that they cover a large number of functional areas, but do you need all these functional areas in one solution in the first place ?
I'd recommend reflecting architectural divisions with projects and functional divisions with solutions. Different solutions can reuse the same projects. This way you'll have one project for each reusable architectural layer and as many Domain projects as there are functional areas.
I definitely wouldn't merge the projects... I think you'll quickly end up with spaghetti code in each layer as the developers take shortcuts (whether they mean to or not) that they shouldn't be taking.
I'd be more inclined to separate the layers out into separate solutions... and use binary references instead of project references across the tiers. This can play havoc with branching though, be careful.
I've seen build times drop by making the projects build to a common place - apparently this can prevent VS rebuilding projects when it doesn't need to - but I don't know if this is true or not.
Some ideas here: http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx
Finally.... is the three minutes for a full build or just to unit test one project? Focus on whichever is the biggest issue. If unit testing is taking a long time, you've got a problem with dependencies. If the full solution is taking a long time, get a build server and focus on bringing your unit test development time down.
Hope that helps
A low impact way I've dealt with a problem like that in the past is to create a series of solution files that include just one of the projects and its test project (and perhaps the project's dependencies). Then, get yourself a tool like NCrunch and do most of your coding in these solutions, probably using TDD. This will give you lightning fast feedback loops and is decidedly in the spirit of the layered, decoupled approach. When I've done this in the past, I find that I only actually run the entire application a few times a day, max, and I rely heavily on red-green-refactor, which is nice anyway.
If you want, you don't even have to source control these little solution files -- developers can create their own and they can be borderline throw-away.
Of course, this is by no means a panacea and won't address the problem of long compile times when you want to run the application, but it can definitely help simultaneously cut down on feedback time while promoting good design/development practice and it has the advantage of being extremely low risk and fast to setup.
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.
My new assignment at work is to create a second version of our existing web application. Currently, our application supports only full time brokers, but now we our launching a second site specifically for part time brokers.
The new site will be almost identical to our existing site with the following exceptions:
It will have it's own branding.
A couple of the user controls used for displaying information will be different (but none of the pages will be different).
Our existing users should not have access to the new site and vice versa.
It needs to be easy to test both versions of the website from within Visual Studio easily.
We want to reuse as much our existing code as possible.
I have 2 weeks to do this.
I'm hoping that this is a common scenario and someone out there has some advice for how to accomplish this.
I really, really don't recommend branching projects or other routes which involve copying what is essentially identical code with the exception of branding and authorization. It will certainly be easier in the short run but, as you said, will become a nightmare very quickly trying to maintain almost-identical code bases.
Your pages can make the decision on what controls to show based who is logged in or even set globally to indicate this is the part-time broker version of the application. You could have a set of views and light logic to handle part time vs. full time brokers. Since the sites are deployed separately, a config setting would be straightforward. If you have other versions of the same site, you may have to give this some thought to ensure it would scale with your other variations.
I would even use the same database as long as you can separate the data appropriate using claims-based (preferred) or role-based authorization or similar.
All this said, there does not seem to be any great reason why you'd want to deviate from using the same code base.
I would create a branch of your code and then work against that. This is of course assuming that you are using version control. You are aren't you?
My first thought would be to
copy the entire source code to another IIS website
script the database over to another database (fresh start for new website)
make necessary adjustments to usercontrols and branding
roll out the new site (as Beta)
In Visual Studio, you can create a new project inside the same solution so that you have access to both projects at the same time.
If you're using Version Control... create a branch, and start customizing from there.
what this will do for you is give definitive separation between the two sites... no users have access across sites, all future customizations will be on a per-site basis, etc.
While I really like the idea CaptainTom posted another solution would be to break off the display layer of your application from the rest of the logic and create a new project that implements the new user experience while sharing the rest of the code
i.e. a FillTimeBrokers project and a PartTimeBrokers project with both implementing their logic from a common Brokers project.
Over time, the code base I maintain has grown exponentially. We have a variety of different utility classes, webparts, event receivers, console applications, and more.
Typically, each webpart lives in a separate DLL (one solution and one project per web part). Our utility classes have also been largely separated out into their own separate DLLs (this includes any specialized list access classes that get grouped with their beans together in a DLL). This has led to a large amount of solutions which has become more difficult to maintain (upgrading each solution to Visual Studio 2008, or simply just trying to find out the maze of DLL references).
With my discovery of the SharePoint Guidance, I'm re-evaluating our current code structure. For example, it looks like they recommend combining all of your specialized list access classes into a Repository (we've done completely the opposite so far by splitting them into DLLs based on what "solution" the code is for).
Questions: How should I be organizing my code? How do you decide what goes into a solution vs project vs folder or what goes in a namespace? One solution per web part?
I usually organize my code by functionality. Let's say I've got an extranet project and some code for some intranet webparts, I seperate it out into a Extranet and an Intranet project, and seperate the different classes of code (eventreceivers, timerjobs, webparts, etc.) into different namespace.
That way, I can deploy (sub)sets of functionality to different farms if I want to, and when editing code I got everything that depends on one another in the same place :)