What is the best practice to create an ASP.NET portal and modules?

Question

Recently, our development team was approached by a representative from one of the departments at our institution looking for a web based solution to help out with their workflow. A few weeks later, another person from that department approached us concerning another solution for a completely different workflow process. Then after that ... yet another request from the same department from a different person.

During our requirements gathering for the various requests, we noticed that there was some common ground between core aspects of the requests. Between the projects some of the users were shared and some where not, some users roles changed between processes, 2 of the apps accessed the same data, 2 of them accessed client data. The individual requests are far from trivial.

Now, we are currently considering creating some sort of portal for this department. The portal would serve as the main entry point to the various modules/ tools that we would make available form them. In addition to that there will be a core database that stores the common data between the applications, and then module specific data would reside in their respective databases.

My question is, what would be the best way develop such a portal in an asp.net, IIS 6, MSSQL 2005 environment. I was thinking to have one app pool created in IIS to be used for all the modules and the portal. Create the portal and each module as separate web apps, and the deploy modules to sub folders underneath the portal app. The portal would just need to serve links to the various modules available. Does this make sense or is there a better way? I know SharePoint would be a good solution if we had the resources to purchase and setup a SharePoint, but we don't.

Answer 1

I would say a simple thing so you don't have any headaches creating something that exists...

for ASP.NET portal and modules use DotNetNuke

it's Open source, so you already have all the code... build upon it!

Answer 2

I was thinking to have one app pool created in IIS to be used for all the modules

Maybe. I'm not saying it's bad - it's just a very low level bit of detail and it sounds like you've got much bigger fish to fry.

I haven't used DonNetNuke, I've know of one company that uses the multi-tenancey modules it has. If the system is workflow intensive you might want to look into workflow systems - K2 BlackPearl is fairly well established in the Microsoft influenced market. If tyou haven't discovered it already (and you're not going to use something like DNN) then the Microsoft Enterprise Libraries are a must-have (see: MS Patterns & Practices and CodePlex).

Other points to consider:

• You want to have a good framework in place that handles all the (truly) common stuff (Logging, etc).
• Keeping the different dept's areas seperate is wise; a project for each of those plus a project for the portal would be my approach. Framework would be seperate again.
• Model the data - even if it's on a whiteboard. Understanding the data (what's shared, what's not, where it comes from and who uses it) is pretty important.
• When looking at re-use: remember to apoply it at the right level. Just because you write a specific UI doesn't mean you have to wriete specific BL and/or DAL for it.
• Use abstraction and Dependency Injection to keep layers apart (particularly the BL and DAL).
• Use the Interface Segregation Principle to keep verticla parts of the system seperate.

Answer 3

" I know SharePoint would be a good solution if we had the resources to purchase and setup a SharePoint, but we don't."

If you mean Sharepoint services, depending on the version you need and what you already have, there might not be any purchase involved. Also check DotNetNuke as @balexandre mentioned.

Above said, if you are going the custom route, I'd focus more on library reuse than deployment aspects to share the core. Having the main site + the 2 app folders is good, but don't make that get you into cross-app calls if simpler library calls would work for your scenarios.

Don't access the core database directly from the 2 apps. Use business level operations to access the data, and define a very clear boundary / with very simple operations. The boundary is very important, if you try to model the 3 projects at a low level at the same time it will only mean unnecessary complexity / both during the analysis and in the resulting product. When thinking on the 3 projects at the same time, keep it hight level as should be the operations involved at the boundary. This is the way it'll actually work, if you later on get other apps/projects - otherwise you'll find yourself with very though decisions with 5+ products of information and a very big headache.