That being said, here’s little reminder about layers of abstraction.\u00a0 They are typically a good thing.\u00a0 Remember though, that in “Scott World” (which is hopefully your world also \ud83d\ude42 ) a “Tier” is a unit of deployment, while a “Layer” is a logical separation of responsibility within code.\u00a0 You may say you have a “3-tier” system, but be running it on one laptop.\u00a0 You may say your have a “3-layer” system, but have only ASP.NET pages that talk to a database.\u00a0 There’s power in precision, friends.<\/p>\n
- \n
- The Presentation Layer: <\/strong>For the vast majority of programmers who are doing ASP.NET, your\u00a0pages live for one reason, to present an interface to the user.\u00a0 That is usually HTML\/XML. (ya, ya, I know you might produce WML, CHTML, or GIFs with HttpHandlers but this whole post is a generalization<\/em>)\n
- \n
- Things your pages shouldn’t know about: <\/strong>Your pages shouldn’t know that a physical data store exists.\u00a0 DasBlog does a lovely job of abstracting away the data store and presenting only an object model to the user.\u00a0 Your ASP.NET pages shouldn’t know about connection strings, Connections, Commands, or anything like that.<\/li>\n
- Things your pages should know about: <\/strong>Your pages should know about your Domain Model.\u00a0 Your objects, your stuff.\u00a0 If you’re a librarian, I suspect you’ll have a Book object.\u00a0 Perhaps a Librarian Service that knows how to Get and CheckOut books.\u00a0 He\/She (the Service) no doubt knows how to Search for Books also.<\/li>\n<\/ul>\n<\/li>\n
- The Business Logic Layer:\u00a0<\/strong>\n
- \n
- Things your BizLogic Layer shouldn’t know about:\u00a0<\/strong>Ideally your business logic layer shouldn’t know there is a database.\u00a0 It shouldn’t know about connection strings or SQL.\u00a0 It shouldn’t know about much of anything except whatever format you choose to represent your objects in (preferably NOT DataSets.)<\/li>\n
- Things your BizLogic Layer should know about:\u00a0<\/strong>It should know about business rules (This payment will need 5 days of lead-time to be paid, or that book can’t be checked out by two people at once) but not the details of storage.\u00a0 It might present public methods like “GetBookByISBN” or “CheckOutBook(Book b)” or “ReturnBook(Book b).”<\/li>\n<\/ul>\n<\/li>\n
- The Data Access Layer: <\/strong>Depending on how “purist” you want to get, you can merge the DAL with the Business Layer.\u00a0 At a minimum you should be able to perform CRUD<\/a> operations.\u00a0 Create, Read, Update, Delete.\u00a0 Fundamentally most apps are just GETS of stuff and PUTS of stuff.\u00a0 Keep it simple.\u00a0 If your backing data store is XML files, or a Web Service or a Database, it shouldn’t matter, and ideally your Business Layer (above) doesn’t even know!\u00a0 It knows there’s a DAL to talk to, but it’s all about responsibility.\u00a0 If you are designing a layer, know your in’s and out’s and for Goodness’ Sake know your responsibility.\u00a0 If you don’t, back to the drawing board until you do.\n
- \n
- Things your Data Access Layer shouldn’t know about: <\/strong>It shouldn’t know about HTML, and it shouldn’t know about ASP.NET.\u00a0 It should avoid knowing about business rules that don’t related directly to how the data is stored (like cardinality<\/a>.)<\/li>\n
- Things your Data Access Layer should know about: <\/strong>It should know about\u00a0accessing data<\/em> in whatever form it’s stored.\u00a0 It\u00a0might have functions like “InsertBook(string name,\u00a0string isbn)” or “InsertBook(Book b)” if you don’t mind it knowing about your Business Objects (I usually don’t).\u00a0 It should act as an Adapter between your Data Access Layer and your Data Store.<\/li>\n<\/ul>\n<\/li>\n
- The Data Store: <\/strong>This might be a SQL Server; then you’ll need CRUD Stored Procedures to ReadBooks, UpdateBooks, etc.\n
- \n
- Things your Data Store shouldn’t know about: <\/strong>Your Data Store shouldn’t be generating messages in language.\u00a0 That means don’t have your Stored Procs generate English messages.\u00a0 Sounds silly, but I’ve seen it before in the wild, so it bears repeating.\u00a0 It’s your Data Store’s job to get data to the DAL, and little else.<\/li>\n
- Things your Data Store should know about: <\/strong>Storing stuff.\u00a0 ‘Nuff said.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
This may seem overkill, but believe me, once you’ve done it a few times, you’ll appreciate it when you come back to mess with the code in the future.\u00a0 Remember also that much of this CRUD stuff can be auto-generated by CodeSmith<\/strong><\/a> or by\u00a0Deklarit<\/strong><\/a>.\u00a0 Please, do resist the\u00a0urge to open up a SqlConnection\u00a0from your next ASP.NET page.<\/p>\n
![\"\"](\"http:\/\/www.hanselman.com\/blog\/content\/binary\/layeredarch.png\")
<\/p>\nWhy should you do this?\u00a0 Because of the ‘ilities and because the simplest even-slightly layered design hides complexity.\u00a0<\/em><\/p>\n
- \n
- Flexibility<\/strong>: “The ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed.”<\/li>\n
- Maintainability<\/strong>: “The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment.”<\/li>\n
- Reusability<\/strong>: “The degree to which a software module or other work product can be used in more than one computing program or software system.”<\/li>\n
- Scalability<\/strong>: “The ease with which a system or component can adjust to changing load.”
\n[All these definitions are from the\u00a0IEEE Standard Computer Dictionary.]<\/em><\/li>\n<\/ul>\nSource:\u00a0hanselman.com<\/p>\n","protected":false},"excerpt":{"rendered":"
I was going over some\u00a0C# code that was written for a non-profit earlier this year.\u00a0 It was fairly typical code and that’s what disturbed me so.\u00a0 It consisted of a single ASP.NET Application with most of the work happening in the Page_Load.\u00a0 Although there was only one database, the connection string to that database appeared\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-636","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/636","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/comments?post=636"}],"version-history":[{"count":1,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/636\/revisions"}],"predecessor-version":[{"id":637,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/636\/revisions\/637"}],"wp:attachment":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/media?parent=636"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/categories?post=636"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/tags?post=636"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Maintainability<\/strong>: “The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment.”<\/li>\n
- Things your Data Store should know about: <\/strong>Storing stuff.\u00a0 ‘Nuff said.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- Things your Data Access Layer should know about: <\/strong>It should know about\u00a0accessing data<\/em> in whatever form it’s stored.\u00a0 It\u00a0might have functions like “InsertBook(string name,\u00a0string isbn)” or “InsertBook(Book b)” if you don’t mind it knowing about your Business Objects (I usually don’t).\u00a0 It should act as an Adapter between your Data Access Layer and your Data Store.<\/li>\n<\/ul>\n<\/li>\n
- Things your BizLogic Layer should know about:\u00a0<\/strong>It should know about business rules (This payment will need 5 days of lead-time to be paid, or that book can’t be checked out by two people at once) but not the details of storage.\u00a0 It might present public methods like “GetBookByISBN” or “CheckOutBook(Book b)” or “ReturnBook(Book b).”<\/li>\n<\/ul>\n<\/li>\n
- Things your pages should know about: <\/strong>Your pages should know about your Domain Model.\u00a0 Your objects, your stuff.\u00a0 If you’re a librarian, I suspect you’ll have a Book object.\u00a0 Perhaps a Librarian Service that knows how to Get and CheckOut books.\u00a0 He\/She (the Service) no doubt knows how to Search for Books also.<\/li>\n<\/ul>\n<\/li>\n
- Things your pages shouldn’t know about: <\/strong>Your pages shouldn’t know that a physical data store exists.\u00a0 DasBlog does a lovely job of abstracting away the data store and presenting only an object model to the user.\u00a0 Your ASP.NET pages shouldn’t know about connection strings, Connections, Commands, or anything like that.<\/li>\n