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.

I have written an ASP.NET WebForms portal for a client. The project has kind of evolved rather than being properly planned and structured from the beginning. Consequently, all the code is mashed together within the same project and without any layers. The client is now happy with the functionality, so I would like to refactor the code such that I will be confident about releasing the project. As there seems to be many differing ways to design the architecture, I would like some opinions about the best approach to take.

FUNCTIONALITY

The portal allows administrators to configure HTML templates. Other associated "partners" will be able to display these templates by adding IFrame code to their site. Within these templates, customers can register and purchase products. An API has been implemented using WCF allowing external companies to interface with the system also. An Admin section allows Administrators to configure various functionality and view reports for each partner. The system sends out invoices and email notifications to customers.

CURRENT ARCHITECTURE

It is currently using EF4 to read/write to the database. The EF objects are used directly within the aspx files. This has facilitated rapid development while I have been writing the site but it is probably unacceptable to keep it like that as it is tightly coupling the db with the UI. Specific business logic has been added to partial classes of the EF objects.

QUESTIONS

The goal of refactoring will be to make the site scalable, easily maintainable and secure.

  1. What kind of architecture would be best for this? Please describe what should be in each layer, whether I should use DTO's / POCO / Active Record pattern etc.

  2. Is there a robust way to auto-generate DTO's / BOs so that any future enhancements will be simple to implement despite the extra layers?

  3. Would it be beneficial to convert the project from WebForms to MVC?

share|improve this question
1  
Release early, release often. I suggest that your client might not care so much if you don't have tangible business issues to present (eg, it's insecure). Perhaps you should clean up a little (make sure it's portable), and release, then take this on as a long term initiative - to morph into MVC or similar. –  gahooa Jul 3 '12 at 18:03
    
Don't change your working project technology to new xyz technology just because it is there, specially if your project is working fine as is. If it is working don't break it. Business does not care about the code. Functionality is all what matters at the end of the day. –  Emmad Kareem Jul 7 '12 at 1:55
    
ok that's true, however my concern is, once it is released it will be harder to refactor because of the risk of breaking it when the stakes are much higher. So we would be stuck with code that is not as maintainable and harder to debug etc. I was tempted to learn / convert to MVP but that looked like too much work. So far I have just converted it to DAL, Domain, UI layers which feels more organised yet still allows the inevitable RAD that will be needed while the project is young. One day if necessary I can expand to MVP or MVC I suppose - after I have enough time to learn how it all works. –  stack man Jul 7 '12 at 3:31
    
What feels messy still is: 1) EF Objects in the UI (code behind files in the UI layer) –  stack man Jul 7 '12 at 3:31
    
(2) Business logic in extended EF objects which had to go in the DAL layer (didn't realise partial classes had to be in the same assembly) (3) Business logic within aspx.cs files in the UI layer. However, it seems that there are often compromises when it comes to architecture but this is certainly a step forward. I feel that this is acceptable for the 1st release and as time goes on we can reassess our approach. Thank you for your help everybody. It is good to get a bit of direction as this area is so subjective. –  stack man Jul 7 '12 at 3:43
add comment

3 Answers

ASP.NET MVP pattern is the best architecture for a long term ASP.NET webforms application. It is coming into play with "separation of concerns" concept, which is de-facto a trend behind the MV* patterns.

The question on Why to use it? - addressed in details in this post - ASP.NET MVP

share|improve this answer
    
The problem is, it would require a lot of work to refactor the project to MVC...if I keep it as a WebForms app with Domain Layer (code first, POCO), Data Access Layer (db context only) and UI, would you consider this an acceptable design for production? At a later date we could consider converting it to MVC I suppose. –  stack man Jul 3 '12 at 2:30
    
Well, it is a MVP (model-view-presenter) pattern and NOT a MVC (model-view-controller). –  Yusubov Jul 3 '12 at 2:33
1  
oh sorry - I misread. Thank you - I will read about the MVP design. –  stack man Jul 3 '12 at 2:37
    
no problem, i hope you will find what you look for :) –  Yusubov Jul 3 '12 at 2:38
1  
Thank you. I will look into using T4. –  stack man Jul 3 '12 at 18:16
show 2 more comments

As ElYusubov mentioned, the MVP pattern can be great.

The key concept is stripping out most or all of your logic from the code-behind. Logic should not be bound to a page. What if you need to re-use the logic from one page in another? You will be tempted to copy-and-paste. If you're doing this then your project will become maintainable.

So, for starters begin refactoring your logic out of the code-behind and put it in a business layer. If you managed to get all the logic out of the code-behind then you could implement the necessary interfaces to be a true MVP.

Also make sure your data access is separate from your business logic. Create a data layer and begin refactoring on that end as well. Since you're using EF4 this is less of a problem as EF should already have this end separate. You should be able to easily move all your EF files to another project and simply add a reference to the projects that need it. The added benefit being, you may need to reference your data model in other projects.

To avoid being overwhelmed, refactor a little at a time. Whenever you touch a piece of code consider refactoring the code around it. If you do this, over time your project can become more maintainable.

Edit

You asked about having the code behind inherit a business logic class. This can't be done because the code behind "is-a" page. C# does not allow multiple inheritance, so the code-behind class cannot be both a page and a custom object. You need to conceptually separate out the logic. Its probably the case that the code in your code-behind is doing many different things. A class should do one thing and one thing only. Try and think about how you may conceptually pull out existing functionality. For example, lets say you have a registration page and you're collecting user information. You probably have a button called register and a click event associated with that button. In that event you are saving user information and doing whatever processing you need. You could create a Registration object to handle all that logic. In the code-behind instead of doing the logic yourself you can pass the information to the Registration object.

This not only a cleaner separation but it can also be a way to self document your code. When someone reads your code they see you calling a Registration object so you know exactly what's going on.

If you wanted to strictly follow the MVP pattern, instead of passing the parameters to the Registration object the code-behind would implement an interface. The implementation of the interface would essentially map all the view objects (text field etc) to the interface. e.g. public string FirstName { get{ return txtFirstName.Text; }}

Once that is done you could pass the page to the Regisration object

Registration.RegisterUser(this);

And this RegisterUser method would take the interface as a parameter

public bool RegisterUser(IUser user){ user.FirstName ...}

public interface IUser { public string FirstName; }

If this MVP sounds confusing, just focus on refactoring and know the point of all this is to maximize code-reuse. There's no since in repeating yourself. That's the DRY principal.

share|improve this answer
    
Thanks for your helpful tips. Yes, I have certainly been a bit overwhelmed with this. It seems to me that MVC would be the best pattern to use but MVP would be easier to achieve and would be the next best pattern. I have always used code behind files so always scratched my head about how business logic can be separated from presentation...so I should be able to essentially move my .aspx.cs files to the domain layer and have an inherits statement in the aspx? Certainly ending up with 3 layers would make me feel comfortable with releasing the 1st version - then I can improve it from there. –  stack man Jul 3 '12 at 18:14
    
I'll respond to your comment in my answer. Feel free to upvote my answer if you found it useful –  coder Jul 6 '12 at 23:49
add comment
  1. Use MVP pattern for separate and logic and UI , so in the future you can move to a different UI technology re-using existing logic
  2. Use the repository pattern between BL and DAL so that you can change to any RDBS reusing the business logic
  3. bring separate layers (Dlls) for BO and DAL which is minimizing maintenance.
share|improve this answer
add comment

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.