The Road to Windows "Longhorn" 2004

The Road to Windows "Longhorn" 2004

原文在：http://www.winsupersite.com/showcase/longhorn_preview_2004.asp

部分翻译：http://www.donews.net/weaver2000/archive/2004/11/23/179738.aspx

It has not been a kind year for Longhorn. Awash as it is in ever-increasing delays, Longhorn has been the subject of barbs from even the most dimmed-minded computer industry columnists, many of whom have begun comparing the Longhorn release to Cairo, Microsoft's aborted mid-1990's object-oriented OS project. And no wonder: Like Cario, Longhorn was to have included the technological equivalent of the kitchen sink, and then some. Clearly, something in Longhorn had to give.

And give it has. As I wrote over three years ago in my assessment of the development of Windows 2000, Microsoft works better when it tackles projects in small steps. "If there's a lesson to be learned here, and I believe there is, it's that the development of monolithic operating systems is over," I wrote. "While Windows 2000 is a great product, its development time and complexity is just too much to ask of customers. In the future, Microsoft will need to work off of a stable base, adding features on a yearly basis. For example, Microsoft should have developed Active Directory and IntelliMirror separately, releasing these products when they were ready. Asking customers to wrap their minds around all of the new features and changes in Windows 2000 is simply too much to ask." Now replace "Windows 2000" with "Longhorn" and "Active Directory and IntelliMirror" with "Avalon and Indigo," and you'll see what I mean. Longhorn was just too big.

As of now, however, that's no longer true. On the afternoon of Friday, August 27, 2004, Microsoft revealed what industry observers had long suspected: The company is now going to pare down its Longhorn release and ship some previously key technologies separately from the massive new OS. But even though the official announcement pretty much lays out this new plan succinctly, there were indications that Microsoft was heading in this direction previously:

It will never ship. No Microsoft product has ever been delayed as much as Longhorn, and as its ship date slipped from 2004 to 2005 to 2006 and even, according to some rumors, to 2007, Longhorn became less exciting to users and more the object of ridicule.

Office 12. Originally planned as a Longhorn-specific release that would ship alongside the Longhorn client release, Office 12 has been changed dramatically since last fall. First, Office 12 would only run on Longhorn. Then, Microsoft announced that it would ship Office 12 for both Longhorn and Windows XP in order to benefit a wider range of users. Now, Microsoft plans to ship Office 12 well ahead of Longhorn.

The on-again, off-again Longhorn Server. Depending on who you asked, Longhorn Server would either trail the client by several years or would ship alongside the Longhorn desktop. This summer, I was told that Longhorn Server would ship about 9 months after Longhorn client. That schedule is apparently still intact under the terms of the new plan.

The breaking of the Fellowship. Since last fall, Microsoft has been preaching the three core pillars of Longhorn as being the WinFS storage engine, the Avalon presentation layer, and the Indigo Web services platform. These features, Microsoft said, were core to Longhorn and couldn't be taken out. During a series of meetings at the Microsoft campus earlier this month, however, I discovered that Indigo was almost completed and would potentially ship separately for Windows XP Service Pack 2 (SP2) and Windows Server 2003. The news astounded me, as it proved Microsoft's earlier contention about the core pieces of Longhorn to be somewhat spurious. What ramifications, I wondered, would this development have on the future of Longhorn?

Back to square one. During the same set of meetings reference above, I discovered that the core Windows team, which had been working to componentized Longhorn, had given up and would restart their efforts using the Windows XP SP2 code base (previous Longhorn builds had utilized the Windows Server 2003 code base). This startling revelation suggested that even further delays for Longhorn could be expected, unless something dramatic happened.

And indeed, something dramatic has happened.

Change is good

According to Microsoft Lead Product Manager Greg Sullivan, the changes came about because of an internal review of where Longhorn was and where it was going. "Basically, coming off of Windows XP SP2, it was a logical time to take stock and evaluate the Longhorn project," he told me. "We needed to establish priorities, and see where we were. As a company, we learned a lot from SP2, and in conversations with our partners around that, and at the PDC with the deverloper community, we had a good handle on what they were expecting. We mapped out a very ambitious plan for Longhorn at the PDC, and we are absolutely on track to deliver on it. How we will get there, however has changed a little bit."

Here's what's changed.

New guidance on the delivery of Longhorn

Longhorn will ship in 2006, Microsoft says. But take that to mean it could happen in late 2006: Instead, Longhorn will be "broadly available" in 2006. That means that Longhorn will be available in early 2006, not in the waning days of that year. "We're providing guidance and clarity on the target release date," Sullivan told me, "which is something we'd never done before. We did issue some guidance on the beta releases, but not on the final release. So that's new. The clarification of our roadmap is good for customers, especially enterprise customers. The implication of our use of the language 'broadly available' is that we're targeting the first half of 2006, and are expecting it to happen around mid-2006. That clarification is a good thing."

Taking key Longhorn features downlevel to Windows XP and Windows Server 2003

Since the PDC last year, developers and ISVs have been practically begging Microsoft to port some of the key Longhorn technologies to Windows XP and Windows Server 2003 so that they can target a wider audience of users. Microsoft has acquiesced to those requests and will port the Avalon presentation layer and the Indigo Web services infrastructure, and the appropriate WinFX developer libraries, to XP and 2003. Those products will ship at the same time as Longhorn.

"We got strong feedback regarding a desire to see the delivery of WinFX elements downlevel," Sullivan told me. "It's the new platform. So we will deliver Avalon and Indigo on Windows XP and Windows Server 2003. That's significant. Instead of waiting for Longhorn to be heavily deployed, developers can target these APIs to 100's of millions of PCs. So that's good news."

And let me dispel a major misconception: The inclusion of Avalon on Windows XP does not mean that XP is getting the Longhorn user interface. It's not. Avalon is a presentation layer that enables rich media experiences and powerful display technologies. But Windows XP will still look like Windows XP after Avalon is installed; all that means is that XP users will be able to take advantage of Avalon-based applications and services. To get the advanced Longhorn user interface, you will still need to upgrade to Longhorn.

WinFS will not be included in the initial Longhorn release

One bit of bad news is that the oft-touted WinFS storage engine will not be included in Longhorn. However, there's been a bit of misconception about WinFS and which features it enables, and Sullivan was quick to clarify that. "Longhorn will still feature a very rich search experience," Sullivan said. "It's kind of a mistake to equate local search with WinFS. They are different platform elements. So local search will still happen, and we will still deliver a very compelling full text search in Longhorn, alongside new shell capabilities. This will provide some semblance of the 'Find My Stuff' experience. But it won't be the full relational store with deep integration and platform exposure via APIs. For end users, however, it will be the same. We will offer a very compelling user experience for local search inside of Longhorn."

WinFS will ship in beta form when Longhorn is released and will now ship simultaneously on both Longhorn client and Longhorn Server, the latter of which is due in 2007. This year-long delay actually answers a key customer request, because there was some confusion previously about whether WinFS would ship with Longhorn Server. Now, Microsoft is clearly telling us that WinFS is a key feature of Longhorn Server. Incidentally, existing Longhorn users will be able to get WinFS for free when it ships, though the delivery vehicle for that product has yet to be announced.

Also, unlike Avalon and Indigo, WinFS will not ship separately for Windows XP and 2003. This technology is for Longhorn-era products only.

So what will be included in Longhorn?

In an email message to all full-time employees on August 27, Microsoft group vice president Jim Allchin said that the company's customers "love our vision" but just wanted parts of it to be delivered sooner. He said that Microsoft will deliver the following in 2006:

• The highest quality OS we have ever shipped

• New information management tools to improve productivity, including fast desktop search and new, intuitive ways to organize files

• Major security advances that build on Windows XP SP2, such as new technologies to make clients more resilient to attack, viruses and malware

• Flexible and powerful tools to reduce deployment costs for enterprise customers, including technologies for image creation, editing and installation; and much simpler upgrades for consumers

• Significant improvements in reliability, including a robust diagnostic infrastructure to detect, analyze and fix problems quickly, and new backup tools to keep data safe

• A platform that creates Developer excitement with the availability of rich APIs [application programming interfaces]

"Our commitment to broad availability of the Longhorn client in 2006 and broadening the API set underscores our long-term vision for the Windows platform, and our desire to deliver high-quality innovations that our customers and developers are asking for in a timely fashion," he said. "We will not cut corners on product excellence. Our powerful vision is intact; our shipment plan changes will let customers get access to parts of the vision faster."

The new schedule

Accordingly, Longhorn now has a new schedule. It's unlikely that Microsoft will issue any more pre-alpha or alpha builds of the product to the public, Sullivan told me. Instead, the Beta 1 release will be the next major milestone and it's now due in early- to mid-2005. There will be a PDC in 2005, but not this year. And Longhorn will hit the release candidate stage in early 2006 and likely ship to customers broadly by mid-2006. "The acceleration of delivery and the broadening of the distribution of Longhorn technologies should be taken as very good news," Sullivan concluded. And now, thanks to the clearer schedule, we can accurately plan ahead.

November 2004 update: A more detailed schedule emerges

According to internal documentation I first reviewed in late October, Microsoft is planning an aggressive schedule for its oft-delayed Longhorn successor to Windows XP and will ship the long-awaited Beta 1 release of that operating system on February 16. The latest release schedule notes that Microsoft will begin locking down the code for Beta 1 in early December 2004 and then enter the so-called escrow phase in early January.

Currently, the Longhorn team has exited the "milestone" phase of development, denoted by releases with names like M8, M8.1, and M8.2, and has entered a pre-Beta 1 cycle known internally as D1. Longhorn is currently scheduled to ship publicly on May 22, 2006, according to this documentation.

In a related development, the Microsoft Office team is busy preparing Office 12, the next major version of Office, which is tied to the Longhorn release schedule. According to the documentation I've seen, Office 12 will ship publicly on the same day as Longhorn, but will follow a different development path. Microsoft will ship various "milestone" builds of Office 12 until late June, when the project will be declared code complete. Then, Microsoft will issue a Beta 1 release on September 26, 2005, followed by Beta 2 in December 2005 and Beta 3 in March 2006.

Given Microsoft's historic inability to meet release schedules, any or all of this information could change over time. But the documentation I've seen is quite recent and represents the current schedule. I find it interesting that the Beta 1 date for Longhorn hasn't changed since April 2004, when I last saw an internal schedule document for the project: Clearly, Microsoft is attempting to make the best of its decision to drop WinFS from the OS.

Longhorn release schedule (internal documentation: October 2004)

Longhorn D1 (a.k.a M9, or milestone 9) development concludes: November 10, 2004
Longorn Beta 1 internal development: November 11, 2004 to November 24, 2004
Longhorn Beta 1 lockdown: November 29, 2004 to January 14, 2005
Longhorn Beta 1 escrow: January 17, 2005 to February 16, 2005
Longhorn Beta 1 release (client and Server): February 16, 2005
...
Longhorn RTM: May 22, 2006

Office 12 release schedule (internal documentation: October 2004)

Office 12 M1 (milestone 1) integration: July 26, 2004
Office 12 M2 final code check-in: November 29, 2004
Office 12 M3 final code check-in: April 18, 2005
Office 12 code complete: June 27, 2005
Office 12 Beta 1: September 26, 2005
Office 12 Beta 2: December 19, 2005
Office 12 Beta 3: March 13, 2006
Office 12 RTM: May 22, 2006

Conclusions

I've been covering Microsoft long enough to be skeptical about even these revised plans, but given what I've heard about the development of the product recently, the new plan certainly makes sense. How the computing world will react after being promised tech nerdvana, however, remains to be seen. For a broad range of power users and technology enthusiasts, Microsoft's Longhorn promises have been severely diminished, even if it happened for good reasons. But I think it's important to keep one thing in perspective: Longhorn will still be a major Windows release, on both the client and the server, and it will likely still stand at the apex of personal computing when its ships. Put succinctly, though the kitchen sink approach is gone, Longhorn remains the OS technology to watch.

--Paul Thurrott

posted on 2004-11-23 13:20:00 by uestc95  评论(2) 阅读(2337)

Palau Platform Introduction (1) - A first look(IV),Palau O/R Mapping 2.0 Feature

Palau O/R Mapping 2.0 特性

       Palau O/R Mapping 2.0是Palau平台的一个轻量级持久层框架，其中包括了持久层的实体设计器和持久层基本组件两部分。

      1．ORM Designer

       持久层设计器是Palau ORM2.0的实体设计工具，利用该工具，开发人员可以创建实体以及实体之间的关系，同时也可以按照vs.net的方式对解决方案进行管理。ORM Designer提供的设计元素包括：实体，实体属性，连接关系，聚合关系，继承关系。实体设计完毕以后，可以点击Build按钮，根据开发人员的设计产生出可以直接使用的.net装配件。

      1.1 实体

实体是业务数据的载体，可以直接由数据库中的某张表生成，也可以手动进行创建。实体的对象对应到数据表中的某条记录，并且在该对象里面包含自己的持久化操作，包括Insert, Update, Delete。实体类包括一些静态的针对数据表的操作，如：Query等。

 

      1.2 实体属性

实体属性是实体包含的公有业务数据。可以由数据库的某个字段生成，也可以手动进行创建。实体属性有持久化属性与运行时属性之分，持久化属性在实体持久化时保存到相应的字段中，而运行时属性只会在运行的时候根据其他属性的值计算出来，本身并不会保存到数据库中。持久化属性可以进行延迟加载（用在属性较大且不常用的时候）。运行时属性的计算规则是用属性的Rule来指定的。

      1.3 连接关系

连接关系描述两个实体之间的关联关系，一般用在存在主外键的情况。关联关系由包含外键的实体指向外键实体，并且用LinkRule描述两个实体的关联关系。关联关系的主实体在删除时，不会根据LinkRule删除符合条件的从实体，只会删除关联关系的DeleteList属性中包含的所有实体。

      1.4 聚合关系

聚合关系描述两个实体之间的包含关系，一般用在存在Master-Detail的情况。聚合关系由Master实体指向Detail实体，并且用LinkRule描述两个实体的聚合关系。聚合关系的主实体在删除时，先根据LinkRule删除主实体所包含的从实体，然后删除聚合关系的DeleteList属性中包含的所有实体。

      1.5 继承关系

继承关系描述两个实体之间的属性扩展的关系，一般用在扩展表的情况。聚合关系由扩展实体指向基本表实体，并且用LinkRule描述两个实体的继承关系。继承关系的基本表实体在删除时，会依次删除所有的扩展实体。

      2．Framework

       ORM框架提供了ORM2.0所依赖的核心功能，如容器，接口，规则解析器等。依靠此框架，设计器中所涉及的实体和关系才可以正常运行。

      2.1 实体接口

所有的实体都必须实现Ientity接口，此接口定义了实体的持久化行为和一些其他的通用行为（比如通过一个DataSet填充自己）。

      2.2 容器

所有实体都通用的容器，实现了作为集合的接口，作为数据源的数据绑定接口，作为实体容器的持久化接口。

特性：

a. 实体集合在设计阶段和运行阶段都可以指定属性的延迟加载

b. 实体集合支持数据绑定功能

c. 实体集合分页功能

d. 支持与数据库的同步

2.2.1 容器的插入

UserEntity objUser = new UserEntity() ;

Expression exp1 = new Expression(objUser.NameProperty,Operator.NotEqual,new object[]{"dd"}) ;

BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

UserEntity objEntity = new UserEntity() ;

objEntity.Name = "Seth" ;

objEntity.BirthDay = DateTime.Parse("1978-1-1") ;

objContainer.Add(objEntity) ;

objContainer.Upload() ;

2.2.2 容器的更新

UserEntity objUser = new UserEntity() ;

Expression exp1 = new Expression(objUser.NameProperty,Operator.NotEqual,new object[]{"dd"}) ;

BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

for(int i=0;i<objContainer.EntityList.Count;i++)

{

((UserEntity)objContainer.EntityList[i]).BirthDay = DateTime.Parse("1963-1-1") ;

}

objContainer.Upload() ;

2.2.3 容器的删除

UserEntity objUser = new UserEntity() ;

Expression exp1 = new Expression(objUser.NameProperty,Operator.NotEqual,new object[]{"dd"}) ;

BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

ObjContainer.RemoveAt(0) ;

objContainer.Upload() ;

2.2.4 容器的持久化

      同容器的插入、更新、删除

2.2.5 容器的数据绑定

UserEntity objUser = new UserEntity() ;

Expression exp1 = new Expression(objUser.NameProperty,Operator.NotEqual,new object[]{"dd"}) ;

BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

objContainer.PageCapacity = 4 ;

objContainer.PageIndex = 2 ;

DataSet ds = objContainer.DataSet ;

      2.3 关系

Palau ORM Framework中的关系对应到设计其中的关联关系和聚合关系，具体通过构造函数的IsComposition参数来指定。关系包含InsertList, DeleteList, UpdateList三个列表，分别记录主实体在操作时，需要附带进行插入，更新，删除的其他实体。这些列表中的实体会与主实体的操作处于同一个事务中。此外关系包含一个Query方法，用来根据主实体和设计时开发人员提供的LinkRule来查询符合条件的从实体集合。

特性：

a.       支持运行时动态的改变LinkRule

b.       支持运行时动态的改变关系类型

c.       支持1 : M, M : N的关系。

d.       所有的操作受自动事务控制

e.       对于继承：基类删除时，所有子类都被遍历并删除。

f.        对于继承：子类插入时，基类插入冲突时，支持选择更新或抛出异常。

 

2.3.1 关系的查询

              UserEntity objUser = new UserEntity() ;

Expression exp1 = new Expression(objUser.NameProperty,Operator.Equal,new object[]{"Kevin"}) ;

BenQGuru.Palau.ORM.Framework.Container container = ((Relation)objUser.Relations[0]).Query() ;

              for(int i=0;i<container.Count;i++)

              {

                   MessageBox.Show(((TeacherUserEntity)container[i]).Score.ToString()) ;

    }

2.3.2 关系的插入

UserEntity objUser = new UserEntity() ;

MyUserEntity objExUser = new MyUserEntity() ;

((Relation)objUser.Relations[0]).InsertList.Add(objExUser) ;

objUser.Insert() ;

2.3.3 关系的更新

      类上

2.3.4 关系的删除

      类上

      2.4 事务控制器

ORM Framework中的事务控制器用来保证一个业务过程中的所有实体操作是处于同一个数据库事务中的。事务不可递归，但是会记录事务的次数。只有在第一次调用Begin时真正的开始一个事务，也只有在最后一次Commit时才真正的提交一个事务，其他的操作知识对计数器进行操作。事务控制器必须保证处于同一个线程内，否则计数器会丢失。

特性：

a.       支持嵌套（内部设有计数器）

b.       线程内安全

c.       提供数据库操作接口

2.4.1 事务的开始

              BenQGuru.Palau.ORM.Framework.TransactionManager.Begin() ;

              try

              {

                   //Do Something here...

                   BenQGuru.Palau.ORM.Framework.TransactionManager.Commit() ;

              }

              catch(Exception ex)

              {

                   BenQGuru.Palau.ORM.Framework.TransactionManager.Rollback() ;

    }

2.5.2 事务的提交

      同上

2.5.3 事务的回滚

      同上

      2.5 实体

所有在设计器中设计的实体都会相应的生成一个.net中实现Ientity接口的实体类。

特性：

a.       实体在设计阶段和运行阶段都可以指定属性的延迟加载

b.       支持运行时动态的指定属性的数据库Schema

c.       实体提供丰富的查询语言

d.       支持扩展表类的继承关系

 

2.5.1 实体的创建：

              UserEntity objUser = new UserEntity() ;

              objUser.Name = "Kevin" ;

              objUser.BirthDay = DateTime.Parse("2002-1-1") ;

              //objUser的Age属性会根据设计时指定的Rule： Year(Now())-Year(BirthDay)进行计算

     objUser.Insert() ;

2.5.2 实体的更新：

              UserEntity objEntity = new UserEntity() ;

BenQGuru.Palau.ORM.Framework.Expression exp1 = new Expression(objEntity.NameProperty,Operator.Equal,new object[]{"9527"}) ;

              BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

              objEntity = (UserEntity)objContainer[0] ;

              objEntity.BirthDay = DateTime.Parse(“2003-1-1”) ;

     objEntity.Update () ;

2.5.3 实体的删除：

              UserEntity objEntity = new UserEntity() ;

BenQGuru.Palau.ORM.Framework.Expression exp1 = new Expression(objEntity.NameProperty,Operator.Equal,new object[]{"9527"}) ;

              BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

              objEntity = (UserEntity)objContainer[0] ;

     objEntity.Delete() ;

2.5.4 实体的查询：

              UserEntity objEntity = new UserEntity() ;

BenQGuru.Palau.ORM.Framework.Expression exp1 = new Expression(objEntity.NameProperty,Operator.Equal,new object[]{"9527"}) ;

              BenQGuru.Palau.ORM.Framework.Container objContainer = UserEntity.Query(exp1) ;

              2.5.5 实体属性的延迟加载：

              UserEntity objUser = new UserEntity() ;

              MessageBox.Show(objUser.NameProperty.DelayLoading.ToString()) ;

posted on 2004-11-22 21:49:00 by uestc95  评论(2) 阅读(2360)

Palau Platform Introduction (1) - A first look(III),Palau Workshop O/R Mapping Designer Tutorial

警告：此文章及其它附属品（如示例代码、截图及音、视频等）均属作者本人所有，此文章内容不得转载和私自拷贝。作者保留对非法转载追究的一切权力！

------------------------------------------------------------------------------------------------

这篇随笔中我们简要介绍一下如何利用Palau Workshop O/R Mapping Designer 来实际在一个项目中应用，以便大家能对于Palau Workshop O/R Mapping Designer有更直观的认识：

下面将会以一个示例引领用户步入ORM设计器的使用，用户在只需一步一步按照指示去做便可以了。

场景

假设我们有一个项目需要对数据库中的Employee表与GuruEmployee表进行操作，GuruEmployee表是Employee表的一个扩展表，追加了作为员工的一些其他数据。在这个案例中，很明显如果Employee表中添加了一个的员工，那么他应当也在GuruEmployee表中存在一条相关的记录，反过来亦然。作为用OO编程的程序员怎么用OO的方式去看待这个业务逻辑呢？是不是我们可以有以下结构呢？

这在面向对象中是一个继承关系，GuruEmployee继承了Employee并对其做了扩展，这正是用户需要在ORM设计器中做的，画出实体与实体之间的关系并定义关系的逻辑。

步骤

1. 按照以上UML图建立一个测试数据库。
2. 创建项目。
3. 创建框图并在框图上画出实体与实体间的继承关系。
4. 编译项目，将生成的源代码与/或程序集部署到用户的VS.NET项目中。

我们将一步一步的创建一个新的项目，步骤如下：

1. 在菜单“Mode”中选择“Develop Mode”。

2. 从工具栏中按下“New Project”。

3. 会弹出这个窗口：
   
   下面是此对话框的描述：
   • Project Name，这里输入项目的名字，名字将作为此项目中所有实体的默认命名空间。
   • Project Description，项目的描述，不在设计器中使用。
   • Product Version，项目的版本，
   • File Version，
   • Output Path，输出目录，所有设计器为此项目生成的文件都将放置于此 ，包括生成的源代码文件与所需要的程序集文件。
   • Assembly Name，程序集名称，指定生成程序集的文件名，注意要包括后缀。
4. 到此为止，我们就已经新建了一个项目了，解决方案管理器如下所示。
   

接下来我们要创建框图与实体，我们会创建示例中所描述的实体，首先我们需要新建一个框图，步骤如下。

1. 在解决方案管理器中右击项目节点，在弹出菜单中选择"New"，在"New"菜单下选择"Diagram"，如下图。
   
2. 这时会出现一个名为"Diagram1"的框图节点，单击以重新命名，命名为"Employees"。
3. 双击打开框图。
4. 首先我们需要添加数据源，右击数据源窗口中的"Data Sources"。
   
5. 在弹出的对话框中填充对你新建的测试数据库的连接选项，如下图所示。
   
6. 数据源被成功添加，现在展开数据源、表，将数据源窗口中的Employee表与GuruEmployee表拖入框图中，如图所示。
   
7. 如果需要的话，可以为实体以及实体属性重命名，双击元素可重命名。
8. 接下来我们要设计实体间的继承关系，在Toolbox中点击"Generalization"，然后从GuruEmployee拖到Employee上。做好后效果如图。
   
9. 由于继承关系需要子实体中有一属性对应到基实体（一般来说就是主外键关系）， 所以我们要设置以下"Link1"的LinkRule属性，为此，我们切换到属性页，并如下图填充。
   
10. 到此为止，我们就设计好了一个简单的ORM项目，接下来我们要编译并部署。

我们已经创建并设计了一个简单的ORM项目，这一章里我们要编译并将生成结果部署到自己的VS.NET项目中去。

编译

在ORM项目处于打开的状况下，选择工具栏中的"Build"按钮来编译项目。如下图。

不久用户就会在Task窗口看到项目已编译成功的提示。

部署

编译好后用户就可以把需要的文件拷贝到真正的项目中了。打开Windows浏览器，找到自己在创建项目时定义的输出文件夹。这个文件夹中会包含四种内容的文件。

1. ORM Framework程序集，除了ORM项目本身的程序集外，其他所有的程序集都是ORM Framework的程序集，ORM项目就是由ORM Framework所支持的，所以这些程序集是必须的，不管用户选择哪种部署方式（源代码或程序集，请看下面）都需要这些程序集。

2. XML文件，属于ORM Framework的一部分，必须与其一同部署，不论选择哪种部署方式。

3. 源代码文件，如果用户希望直接将源代码添加到自己的项目中而不是引用一个编译好的程序集时，可以将源代码以及ORM Framework的程序集添加到自己的项目中。

4. ORM项目的程序集，如果用户希望直接引用编译后的程序集而不需要源代码的话就可以以程序集的方式部署。

选择一种适合的部署方式，根据以上描述将你需要的文件拷贝到任何用户需要的地方。

posted on 2004-11-22 21:48:00 by uestc95  评论(0) 阅读(1527)

Palau Platform Introduction (1) - A first look(II),Palau Workshop O/R Mapping Designer

posted on 2004-11-22 21:47:00 by uestc95  评论(0) 阅读(1639)

Palau Platform Introduction (1) - A first look

posted on 2004-11-22 21:46:00 by uestc95  评论(3) 阅读(4488)