CODEWITHSUNDEEP
c#asp.net
corymathews
corymathews

Reputation: 12619

Best practices for how to Layer a ASP.NET/C# web app

I have been working on an ASP.NET/C# web app for some time and its size has gotten way to large for how it is being programmed. It has become very hard to maintain and getting harder quickly, something that used to take an 1hr to update now takes about 3-4hrs.

I believe that reworking the app to use different layers would help solve many of these problems. However the more I read the more it seems that everyone does it differently, but achieve mostly the same goals.

I have seen layers such as Presentation/UI, DB, Business, Services, ect. It appears that a 3 layer may be the best but I am unsure.

What layers should I have in a web app and what should each include or be limited to?

Words from previous experience are most appreciated.

Upvotes: 2

Views: 2089

Answers (7)

RickNZ
RickNZ

Reputation: 18654

Traditional layering is only part of the solution. Since that was your question, though, I know many very large sites that layer by presentation, business logic and data access.

However, there's much more that you could / should do, including:

  1. Tiering and division-of-labor: partition business logic between the web tier and the data tier in a maintainable way (usually implies using stored procedures instead of dynamic SQL)
  2. Refactoring your application. In many sites, pages get large and unmanageable due to insufficient attention to continual refactoring. Use approaches such as custom user controls, Master pages, common page base class, ASP.NET skins, page adapters, control adapters, HttpModules, etc, to move your application-wide logic into centrally manageable locations.
  3. Careful adherence to OO design principles.
  4. Strategic use of events to help ensure consistent separation of concern.

Upvotes: 0

sleath
sleath

Reputation: 871

I believe it's heavily dependent on the requirements and whats needed. There is many types of design patterns of ways to structure a app. I've found it helpful to fully digest what I'm trying to accomplish from the requirements and find a match to patterns on this website. Give or take unique circumstances.

http://www.blackwasp.co.uk/DesignPatternsArticles.aspx

This site actually breaks it down design pattern by design pattern. Allowing you to make a good match based on your requirements and scalability needs.

Upvotes: 0

Jerod Venema
Jerod Venema

Reputation: 44642

Check out the Microsoft MVC model for ASP.NET. The issues you described are very common to ASP.NET applications, and refactoring it to match the MVC model might be the way to go. Don't get me wrong - it'll definitely take some work - but IMHO, it'll be worth it.

Upvotes: 0

Marek Tihkan
Marek Tihkan

Reputation: 1914

Mainly it is just managing dependencies.

Good examples are Sharp Architecture projects and Arc projects. You may download some open-source example applications for gaining more insight.

Upvotes: 2

bytebender
bytebender

Reputation: 7491

Your correct in saying everyone does it a little differently. This is how we do it:

Domain

Model - class objects such as Customer, Account, etc.
LookUp - value objects such as AccountType, IndentityType, etc.
Repositories or DataAccessObjects current we use LinqToSql and SQLClient on our older applications.

Service

Services for each of the models or Aggregates. You could also call this the application layer. The idea is we could change to a different UI and it would involve as little as possible code changes.

UI

Currently we are using Asp.net and MVC in our newer applications

The idea is that we can insert different "things" into the layers and not effect the others. ex. If I start using EntityToSql the UI or the Service layer is none the wiser. It just knows it creates an IRepository and calls the FindAll() method. We are also converting older applications to MVC and before we do that we seperate them into these layers so when something else comes out we would like to implement our Service and Domain layers don't have to be changed.

It's important to always be asking your self where should this live? Logic in your UI should really be confined to UI logic. The important thing is to have everyone on your team understand your way and be willing to implement it...

Upvotes: 5

Chris
Chris

Reputation: 6325

Seperation of concern might be a better way of looking at your web application and breaking things up. For say, if you have one page that is doing data access, validation and displaying of items you could take each one of those items, and create it's own class so that you have only one type of thing happening in each class. Then as you go through and start to refactor your code you can then start grouping same type classes into the same type folders, namespaces and projects.

Good luck, you've got a lot of work ahead of you.

Upvotes: 0

user151323
user151323

Reputation:

I believe the common approach is to have 3 layers: presentation, business logic and data access. It should provide for a good foundation.

Having said that I need to point out that division into layers may not help very much with ASP.NET WebForms project. The biggest issue of this framework is its code behind which lures developers into creating monster pages that talk to all layers and services simultaneously to fetch the data to display. The cure is to work out this presentation layer first and let the code only interact with one specific layer (most usually, the business logic). When (and if) this is done, then the project may be successfully refactored.

Upvotes: 5

Related Questions