Layers in ASP.NET


Alex complains about ASP.NET forums v1 which seems to have a
ASPX pages 
---------------------------------------------------------------------------- 
Custom server controls 
Business logic layer (ie Threads class containing static methods) 
Custom objects (ie Thread and ThreadCollection classes containing the OO data representations of what is in the database) 
Data Access Layer 
Stored Procedures in SQL Server 
---------------------------------------------------------------------------- 
Database tables in SQL Server


structure to it. I have not used that specific tool but the problem seems generic enough. When have you over-engineered or over-architected a product? How do you know you have done that?

There are certain questions/conclusions he brings up that are interesting.

1. Users don’t care what’s happening behind the scenes – they’re looking for information.
Yes and no. Yes if this is an application deployed in the open. But, if you are an ASP or ISV then you need to think about these very carefully. If you arent architected correctly and you can do a flashy song and dance in front of customers, you aint getting them.



2. Extra tiers make maintaining/enhancing a site far more difficult.

True. But, again it depends on the load you are expecting. If you are developing the site like its 1999, then you can plop/glue/mash pages with backend any which way you like. But, once you start thinking about the problems beyond the things you code for, you will realize that there is some meaning to layered approach. This is where you separate the great from the avarage. If you are a great architect, you see the places where you dont have layers and if you are average, you see it everywhere.


3. Successful web applications are able to change rapidly based on user feedback.

No comment here. Since this is a statement. Yes. I agree.


4. What do you gain from replicating the database structure in your middle tier?

The question is fair. You dont gain anything if you think database and the middle tier are the same. This is why I dislike solutions that map tables to classes. It does not work that way. Middle layer is meant to solve problems where database is inefficient. For e.g. If you need to just get the full name of a person when the database last name and first name, you can do the concat in the database or you can do it in the middle layer. But, depending on your response time/perf requirements, you might be optimizing quite a bit if you concat in the middle layer since they handle strings better..



Ok.

3 thoughts on “Layers in ASP.NET”

  1. Very interesting response, Girish. I’m always keen to sit back and say, "What advantages can .Net give us?". If the answer is, "complex architectures for pushing data in between web pages and SQL Server", then we aren’t really using it very efficiently.

    With your point (4), can you think of a better example than string concatenation where you feel a task would be better performed in the middle tier rather than the persistence medium?

    I was saving this for my next weblog post but… My usual approach is thus: as I’m building the code behinds for the webforms, if a code behind reaches a certain level of complexity, or I am using the same bit of code in more than one code behind, I start putting things in static methods in class library files.

    When I’m building Windows applications, I always go all out for object oriented architecture. I recently wrote a POP3 client as a command line app (reads emails out of a mailbox into a database). I used a whole bunch of objects (MailBox, Message, Attachment etc) which made the process a lot quicker.

    But for the purposes of interfacing a web page with a database, these objects would be a lot less than helpful.

  2. I am still thinking about this. I understand your concerns about .NET. But, does it really bring complex architectures or is it the availability of the building blocks that make architects go a little boink boink?

    As for 4, think of a simple address change in HR. Now, think of the workflows involved here. Now, ultimately, the persistent store will contain the new address. But, before that we need many people to be notified about it and some might need to take action on it (such as payroll). In that case, can you really say its justa data being pushed between ASP and SQL or there is something more in between that probebly needs to happen and that in turn might need a layer..

  3. I believe that any DataLayer must be a simple code block, that they allow operations against DB.

    That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.

    Finally, I invite to you to download the DataLayer.Primitives Public Version.

    This is very cool Data Layer :)

    DataLayer.Primitives – Readme!

    http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1389

    Cheers,

    Javier Luna

    http://guydotnetxmlwebservices.blogspot.com/

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>