我很喜欢ASP.NET 2.0中的以DataSet为核心的DAL，它提供了DataSet, DataTables, TableAdapters等等对于数据库的完美模拟。我可以使用VS2005提供的DataSet Designer, Wizard等工具完成创建和配置DAL的工作。
ObjectDataSource与DAL的结合，把这个方便延伸到了UIP层和UI层。我现在要考虑的是，是否给每一个用到ObjectDataSource的server control提供一个自己用的ODS，还是共用。
这两天考虑最多的一个问题是Tiers/Layers问题。这是一个争论广泛似乎没有答案的问题。下午试用Google Pages做网站时受了启发。任何一种架构，存在了就是合理的，就应是满足了某种需求解决了某类问题。所以，为什么一定要为所有的问题找一个统一的解决放案呢？互联网网站有大有小、有简单的有复杂的、有专一的有综合的、有长久发展的有临时实验的，千姿百态，共性的东西其实并不多。这样的话，寻找一种能够包容所有问题域的解决方案似乎就挺不务实的。一个方案解决所有问题，听上去似乎很好：统一了开发过程。可是执行起来就有问题了：无论网站大小，都用同样的架构，写同样多的基础代码。如果做十个网站有八个是短平快且不相似的，那开发成本是提高了而不是降低了。
大型的网站，像Amazon，ebay，Taobao，Yahoo，My Space，其架构、技术、开发都是工业级的，自有Enterprise的方法和技术。
专一的网站：Flickr，Delicious，BaseCamp等所谓Web2.0网站，有Getting Real思想指导下的过程。
普通的网站，比如那些企业门户，又可以用简单快速的技术实现。
个人的网站：比如Blog，比如个人portal，更可以根本不需要编程就实现，比如使用Windows Live Space，Google Pages。
不同类型的网站，可以使用不同的架构、不同的语言、不同的过程来实现。所以，对于Tiers/Layers问题，如果说Case by Case不是一个好的答案，那么Type by Type应该算是一个还好的答案。
Recommended Blogs on Architecture
Web Applications: N-Tier vs. N-Layer - Benefits and Trade-Offs
Should all apps be n-tier?
Avoid Chatty Interfaces Between the Tiers in Your ASP.NET Web Application
What is n-Tier Architecture?
N-Tier Web Applications using ASP.NET 2.0 and SQL Server 2005
http://msdn.microsoft.com/architecture/shareideas/sharebrowseblogs/
How to centralize these business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL.
In a real-world application, the BLL should be implemented as a separate Class Library project; however, for these tutorials we'll implement the BLL as a series of classes in our App_Code folder in order to simplify the project structure.
When working with data one option is to embed the data-specific logic directly into the presentation layer (in a web application, the ASP.NET pages make up the presentation layer). This may take the form of writing ADO.NET code in the ASP.NET page's code portion or using the SqlDataSource control from the markup portion. In either case, this approach tightly couples the data access logic with the presentation layer.
The recommended approach, however, is to separate the data access logic from the presentation layer. This separate layer is referred to as the Data Access Layer, DAL for short, and is typically implemented as a separate Class Library project.
ATTENTION: The following words are picked out with my respect from Mr. Brian Noyes's essay Build a Data Access Layer with Visual Studio 2005 DataSet Designer publish at theserverside.net http://www.theserverside.net/tt/articles/showarticle.tss?id=DataSetDesigner
Almost as common as the debate over which .NET language to choose is the argument about whether to use DataSets or not. As described above, typed data sets are easy to generate through the designer, provide a type safe API for containing business entity data, and already support advanced features such as change tracking, sorting, filtering, and searching. Some of the resistance to DataSets resulted from several performance shortcomings in the .NET 1.1 implementations. These problems included poor performance when working with large DataSets and the fact that DataSets always serialized themselves as XML, which had bandwidth and performance implications when passing DataSets across remoting boundaries. These problems have been fixed in .NET 2.0 and there have been a large number of other improvements. If you dismissed DataSets in .NET 1.1, they deserve another look.
The alternative to using DataSets is to create custom object types that represent your business entities, and custom collection types to contain them. When you go this route, you end up needing to write a lot more code yourself. This has gotten a lot better in Visual Studio 2005 and .NET 2.0 with the additions of code snippets and generic collection classes. But to support the full range of features that a DataSet provides, there is still a fair amount of custom code that you will need to write by hand.
Custom objects have the advantage of giving you explicit and complete control over the way the type is designed, what its internal capabilities are, and what the API is that is exposed from the object. If you prefer a pure object-oriented design approach, then custom business entities will feel a little more comfortable to you. You can accomplish almost anything with a typed data set that you can with a custom business entity, but some things may be a little less clean with a typed data set if the things you are trying to do don’t map well to the relational nature of a typed data set. But if you are primarily getting business data for the purposes of presenting the data, allowing the user to work with the data, and then will persist the data back to the database, you will be able to get things done quicker with typed data sets if you harness the features of the DataSet designer.
When you work with data in an application, the data is usually partitioned into different types of logical business entities, such as Customers, Products, Employees, and so on. To work with that data, you need to encapsulate those logical entities into objects that you can deal with in your code. You could write a custom class for each entity type. Those entity types would expose properties for each of the data values that the entity includes. You would then also want to create a custom collection type for each entity type so that you could have strongly typed collections to contain those entities.
Typed data sets represent an easy alternative to creating and maintaining all those custom types yourself. Essentially what you are doing when you create a typed data set is that you are creating a set of custom type definitions to contain logical business entities and collections of those entities, similar to writing those types by hand. The difference is that you are doing it in a declarative way through the designer that is easy to visualize, edit, and keep synchronized with the database schema that populates those business entities. The code generation of Visual Studio takes care of writing all the underlying properties and methods that give you a strongly typed API for dealing with those business entities in your consuming code. Additionally, because these types are inheriting from the ADO.NET types, you inherit the rich relational data manipulation functionality from those types. These types are also aligned well with the data binding capabilities in Windows Forms and ASP.NET, so if you will be setting up data binding using the objects, then you have less work to do on that front as well.
Finally, and perhaps most importantly, when you create typed data sets in Visual Studio 2005 from a database, you also get a table adapter type created for each table that you add to the data set. A table adapter is a full fledged data access component that lets you retrieve and update data from the database. It encapsulates a connection, a data adapter, and a set of command objects that allow you to execute queries to the database. I’ll get into more detail on table adapters in a little bit.
When you go with typed data sets in Visual Studio 2005, you can actually support most of the same design styles that you could with custom business entity types. The data access code will always be separated into the table adapter types generated by the designer, or into data access components that you write. But you can add custom validation and other logic into your business entity types (the typed data row or data table classes) through partial class extensions. Each of the types created as part of a typed data set definition (data set, data table, data row, and table adapter) are defined in the generated code as partial classes. This feature in .NET 2.0 allows you to supplement the designer generated code with custom code that becomes part of the compiled type, but you do so through a separate code file. This prevents your code from being destroyed if you choose to regenerate the designer generated code.
Another argument that comes up a lot against using DataSets is the assertion that if you are using DataSets in your presentation or business layer, then you are tightly coupling your application to the data tier. This does not have to be the case. First off, you should consider using stored procedures as a layer of decoupling between your actual data tier schema and your application. Your stored procedures can then return and work with result sets that map well to the business entities that you will be manipulating in your application. Additionally, if you need to provide additional decoupling beyond what the stored procedures provide, you can transform data that has been placed into a DataSet into either a different (decoupled) typed data set definition or a custom business entity type in your business or data access layer.
The designer allows you to very quickly create customized query methods in the table adapter that makes it so you will rarely have to write any ADO.NET code yourself if you are working with typed data sets.
All Tutorials:
http://www.asp.net/learn/dataaccess/default.aspx?tabid=63
Tutorial 1: Creating a Data Access Layer
http://msdn.microsoft.com/asp.net/reference/data/default.aspx?pull=/library/en-us/dnaspnettut/html/aspnet_tutorial01_dataaccesslayer_vb.asp
Tutorial 2: Creating a Business Logic Layer
http://msdn.microsoft.com/asp.net/reference/data/default.aspx?pull=/library/en-us/dnaspnettut/html/aspnet_tutorial02_businesslogiclayer_vb.asp
Tutorial 3: Master Pages and Site Navigation
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspnettut/html/aspnet_tutorial03_masterpagesandsitenav_vb.asp
Tutorial 4: Displaying Data With the ObjectDataSource
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspnettut/html/aspnet_tutorial04_datawithobjectdatasource_vb.asp
Tutorial 5: Declarative Parameters
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspnettut/html/aspnet_tutorial05_declarativeparameters_vb.asp
Tutorial 6: Programmatically Setting the ObjectDataSource's Parameter Values
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspnettut/html/aspnet_tutorial06_programmaticallysetparamvalues_vb.asp
