摘要:上个月底，MSDN上一个重大事件是Enterprise Library 1.0的推出。Enterprise Library 1.0把原先陆续推出的几个应用程序编码块(Application Blocks)更新后以统一的风格集中在一起，其扩展性和易用性大大增强，并提供了一个简单易用非常powerful的配置编辑工具 其中的Data Access Application Block有了很大的变化。ADO.NET中遭人批评的一点是没有提供一个共同界面在保持最佳性能的情形下来操作不同数据库(虽然有不少人做了类似努力，譬如参考这里)，这种情形在早期Data Access Application Block版本中也没什么改变，但在Enterprise Library中的版本中推出了database-agnostic APIs。虽然还只支持SQL Server, Oracle, DB2，但你可以写自己的Provider来操作其他的数据库。譬如，你可以写类似下面的编码，只要在相应的配置文件中改变连接字符串以及Data Provider类名，即可操作其他数据库 using Microsoft.Practices.EnterpriseLibrary.Data; Database db = DatabaseFactory.CreateDatabase();DBCommandWrapper dbcw = db.GetSqlStringCommandWrapper("select au_lname as LastName, au_fname as FirstName from authors");using (IDataReader reader = db.ExecuteReader(dbcw)){  DataGrid1.DataSource = reader;  DataGrid1.DataBind();} 跟Enterprise Library相关的连接 Enterprise Library下载 Enterprise Library Home Enterprise Library Community Site Blogs: Tom Hollander Scott Densmore Hisham Baz commences Martin Granell...[阅读全文]

摘要:有位网友把微软的PetShop 3.* 用开源技术重写了，要我提提意见。 首先，我要对这位网友表示感谢，支持和鼓励，让我们见识到了Java世界里时兴的技术/模式在.NET开发中的具体应用。随着这些时兴技术不断地移植到.NET中，我们开发人员会有越来越多的选择。你不需要等ObjectSpaces，类似技术已经在这里。 我的看法是，微软的PetShop 3.*，除了跟Sun的J2EE版本做比较外，主要是提供了一个可做参考的样品，在当前.NET的框架，类库下，怎么手工实现分层应用。这里面涉及很多细节，怎么设计业务层/持久层，怎么做事务，业务层与持久层怎么交互，表现层怎么跟应用层交互，等等，这对初学者来说，是个很好的指导，让人了解在多层应用中，具体都需要做什么。由于O/R的差别，在大型项目中，很多时候大概会用专门的O/R Mapper或持久框架。象NHibernate这样transparent，non-intrusive的技术，指明了很好的方向。但不管用什么，多层应用里所涉及的细节都是需要了解的。在这一点上，对一个.NET开发人员而言，我想，微软的PetShop serves its purpose。 我同意，微软的PetShop要真正成为Best Practice的样板，有不少需要提高，完善的地方。譬如他们的Domain Model，用Martin Fowler的说法是有点贫血(Anemic)，但这也许是因为这应用本身没有多少业务逻辑，有人指出过里面不少的缺点，也有人指出过SQL Server / Oracle的实现是否用Bridge模式来实现更恰当些。 但我觉得，这位网友把几个层都做了大改动，基本上就是重写了，不再是“重构”了。而且我觉得这位网友没必要局限于微软的PetShop implementation，而应该从原来的J2EE的blueprint出发，用那些开源技术完全重新实现PetShop，也许更可体现这些技术的好处。同时希望这位网友能把其中的要点写成文章发表。 需要指出的是，象NHibernate/Spring.Net等技术还是在Beta甚至Alpha阶段，在正式的production项目中，要慎用...[阅读全文]