Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My company is rewriting our proprietary business application. The current architecture is poorly done and inflexible. It is coded more procedural oriented as opposed to object oriented. It has become difficult to maintain.

Our system is a web application written in .Net Webforms. I am considering ASP.Net MVC for the rewrite.

We intend to rewrite it with a good, solid architecture with the goal of maintainability and reusable classes for some of our other systems and services. We would also like the system to be customizable for different customers in the event that we market the system.

I am considering redesigning the system based on the layered architecture (Presentation, Business, Data Access layers) described in the Microsoft Patterns and Practices Application Architecture Guide. http://msdn.microsoft.com/en-us/library/ff650706.aspx

Hopefully this isn't too open ended, but how would you recommend allowing for different business logic/rules for different customers? I'm aware of Windows Workflow Foundation, but from what I've read about it, it seems many business rules could be too complicated to handle there.

Also, Can anyone point me to where I can download an example of a .net solution that is based on the Application Architecture Guide? I have already downloaded the Layered Architecture Solution Guidance and the Expense Sample on codeplex. I was looking for something a bit larger and more robust that I could step through the code and see how it works.

If you feel there are better architectures to base our redesign on please feel free to share.

I appreciate your help!

share|improve this question
1  
You talk about horizontal segmentation of your architecture here which is important, but ignore vertical segmentation at your own peril! Vertical segmentation is for example, taking a store front application and having a completely independent piece of software generate the store front, independent piece of software generate the store's inventory management, independent piece of software generate the store's user account management. Each of these 3 having boundaries between them in similar fashion to the boundaries between your horizontal segments (ui/bl/dal). Each one having ui/bl/dal also. –  Jimmy Hoffa Sep 21 '12 at 14:18
1  
The benefits to vertical segmentation are immense for maintenance, you end up with the ability to make large changes to whole sections of your system (rewrite a vertical segment's dal for instnace) knowing it will in no way effect the other vertical segments. This saves TONS of regression testing time. –  Jimmy Hoffa Sep 21 '12 at 14:19
    
Hopefully you heard of the second-system effect before (en.wikipedia.org/wiki/Second-system_effect)? If not, I recommend you get a copy of en.wikipedia.org/wiki/The_Mythical_Man-Month –  Doc Brown Sep 21 '12 at 15:00
    
Great point Doc Brown. Our current system is actually an elephantine, feature laden application as is. For example, we have 7 different pages with 7 different ways to maintain our users' passwords to their customers' websites. Another goal of the rewrite is to do away with the fluff and streamline it to include only what is needed to do business. –  Ken Sep 21 '12 at 15:10
    
Thank you, Jimmy Hoffa. I am not so familiar with vertical segmentation but I am definitely going to look into that as well. –  Ken Sep 21 '12 at 15:14
add comment

1 Answer

up vote 4 down vote accepted

I suggest you look into something like the Managed Extensibility Framework from .NET 4. If you use that, you would define certain extension points in your software and then fulfill those extension points with DLLs that you drop into your application at run-time.

So, you might have an extension point for a UserListService that has a default implementation that uses an internal database, but if it finds another implementation in the directory, it would end up using CustomerXYZUserListService which goes and pulls in a user list from their ERP system.

share|improve this answer
    
+1 The MEF is very easy to use and purpose built for this reason. –  Jimmy Hoffa Sep 21 '12 at 14:21
    
While MEF looks neat, it's hard to trust MS not to change direction and depreciate it within 6-18 months. Or, perhaps worse, they present a half-baked solution that has serious limitations, quirks and bugs (I'm looking at you SSRS). –  jfrankcarr Sep 21 '12 at 17:06
    
jfrankcarr, can you please elaborate on SSRS? Before the rewrite, we already decided to migrate all of our reports away from Crystal and into SSRS. We are slowly but surely moving in that direction. –  Ken Sep 21 '12 at 17:38
    
@Ken - It depends on the type of reports you need to do. SSRS shines at simple, web based, self-serve reports. One problem comes in when you start needing to support those "different customers" you referred to. For example, CustA has a very specific Excel format they want and CustB wants a PDF that looks just so. A second problem is that the SSRS design tools are a bit buggy/quirky and you'll end up editing raw XML more than you might expect, sometimes to fix problems the tool 'helpfully' created. –  jfrankcarr Sep 21 '12 at 21:26
    
@jfrankcarr - Those are some pretty bold statements not backed up by much evidence in my opinion. MEF is part of .NET and .NET is their flagship development framework, particularly for business applications, and it's still in very active development. We use SSRS for our reports, and everyone pretty much agrees it's quite good, and swear it's much better than Crystal Reports (not to mention it's free). –  Scott Whitlock Sep 22 '12 at 17:13
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.