包装DAO，无论好坏 [英] Wrapping DAO, for better or worse

问题描述

我有一个非常难看的问题，我需要一些真诚的指导。


我的遗留VB6应用程序在很大程度上依赖于DAO，特别是因为它与b $ b相关数据库对象的自定义属性。据我所知，这些自定义

属性不能用于SQL Server，

我们需要在不久的将来迁移到它们。


我的老板，公司的老板，要求我们提供一个

过渡计划，最小化（他真的不需要）代码更改为

现有的应用程序（超过8000个客户端使用）。我们还要求所有

现有安装基础100％向后兼容，因此我们永远无法放弃支持

Jet DBs。 （是的，从来没有很长时间，但他仍然支持18年前他的DOS

产品！）


他希望的解决方案是我们创造了一个一组VB.Net接口类

，它提供了与现有代码库类似的DAO接口。然后，我们

在VB.Net中实现两个工作类，一个通过Interop使用DAO，

然后几个月后实现一个ADO.Net工作类for

模仿Jet的自定义属性的SQL Server（这部分是直接的，因为我们可以使用特殊的表来实现这一点。）


当我正在探索这个主题时，似乎我将不得不制作我的

自己的集合类（例如DAO记录集对象）和

将这些传递给应用程序，基本上是缓存DAO数据。呸。我b $ b可以看到内存使用和性能正常下降，更不用说

未能正确实现一些

方面的意外后果DAO。


如果我有我的druthers我会从一个干净的石板开始重新构建

这个应用程序给它一些合理的面向对象的结构和采取

所有.Net必须提供的优势 - 这是不会发生的。


是否有任何_sensible_方法来解决这个问题？


Sean

I have a very ugly problem and I need some sincere guidance.

My legacy VB6 application depends heavily on DAO, especially as it
relates to custom properties on database objects. These custom
properties are, as I understand it, not avabilable with SQL Server,
which we need to migrate to in the not too distant future.

My boss, the owner of the company, requires that we provide for a
transition plan that minimizes (he really wants none) code changes to
the existing app (which is in use by over 8000 clients). It is also
required that we provide 100% backward compatibility with all of the
existing installed base, so we will never be able to abandon support for
Jet DBs. (Yes, never is a long time, but he still supports his DOS
product of 18 years ago!)

His desired solution is that we create a set of VB.Net interface classes
that presents a DAO like interface to the existing codebase. Then, we
implement two worker classes in VB.Net, one that uses DAO via Interop,
and then a few months from now, implement an ADO.Net worker class for
SQL Server that mimics the custom properties of Jet (this part is rather
straight forward, as we can do this using special tables.)

As I am exploring the topic, it seems that I''m going to have to make my
own collection classes (for the DAO recordset object, for example) and
pass those back to the app, essentially caching the DAO data. Yuck. I
can see memory usage and performance going right to hell, not to mention
the unintended consequences of failing to correctly implement some
aspect of DAO.

If I had my druthers I''d start over with a clean slate and rearchitect
this app to give it some reasonable object oriented structure and take
advantage of all that .Net has to offer - that just ain''t gonna happen.

Are there any _sensible_ approaches to solving this problem?

Sean

推荐答案

一段时间内，他还没有和DAO搞砸。如果要为数据库对象存储自定义

属性，那么如何将它们存储在数据库中的表中？您可以将SqlClient功能包装在

显示客户属性的类中，并且应该很好地隐藏来自

程序员/用户的更改。至于100％向后兼容性，ugghh ...

我可能只是提供一个升级工具，让旧的

产品的用户进入新世纪...之后所有，MSDE都是免费的...


" Sean Kirkpatrick" < NA ********** @ community.nospam>在留言中写道

新闻：％2 **************** @ TK2MSFTNGP09.phx.gbl ...

Uggh haven''t messed with DAO in a while. If you want to store custom
properties for your database objects, how about storing them in a table in
your database? You can wrap the SqlClient functionality in classes that
present the customer properties and should hide the changes from the
programmers/users pretty well. As for 100% backward compatibility, ugghh...
I would probably just provide an upgrade tool to get users of the old
product into the new century... After all, MSDE is free...

"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

我有一个非常难看的问题，我需要一些真诚的指导。

我的遗留VB6应用程序在很大程度上依赖于DAO，尤其是它与数据库对象上的自定义属性相关。正如我所理解的那样，这些自定义属性不能与SQL Server一起使用，我们需要在不久的将来将其迁移到

我的老板，所有者该公司要求我们提供一个过渡计划，以最小化（他真的不需要）代码更改现有的应用程序（超过8000个客户使用）。还要求我们提供与所有现有
安装基础的100％向后兼容性，因此我们永远无法放弃对Jet DB的支持。
（是的，永远不会是很长一段时间，但他仍然支持他18年前的DOS产品！）

他想要的解决方案是我们创建一组VB.Net接口类
DAO喜欢现有代码库的接口。然后，我们在VB.Net中实现两个工作类，一个通过Interop使用DAO，然后几个月后，为SQL实现一个ADO.Net工作类服务器。模仿Jet的自定义属性（这部分是相当直接的，因为我们可以使用特殊的表格来做到这一点。）

当我正在探索这个主题时，似乎我是将不得不制作我自己的集合类（例如DAO记录集对象）并将这些集合传递给应用程序，基本上是缓存DAO数据。呸。我可以看到内存使用情况和性能正常下去，更不用说未能正确实现DAO某些方面的意外后果了。

如果我我的druthers我会从一个干净的石板重新开始并重新构建这个应用程序，以给它一些合理的面向对象的结构，并采取.Net提供的所有优势 - 只是ain''会发生。

是否有任何_sensible_方法来解决这个问题？

Sean

I have a very ugly problem and I need some sincere guidance.

My legacy VB6 application depends heavily on DAO, especially as it relates
to custom properties on database objects. These custom properties are, as
I understand it, not avabilable with SQL Server, which we need to migrate
to in the not too distant future.

My boss, the owner of the company, requires that we provide for a
transition plan that minimizes (he really wants none) code changes to the
existing app (which is in use by over 8000 clients). It is also required
that we provide 100% backward compatibility with all of the existing
installed base, so we will never be able to abandon support for Jet DBs.
(Yes, never is a long time, but he still supports his DOS product of 18
years ago!)

His desired solution is that we create a set of VB.Net interface classes
that presents a DAO like interface to the existing codebase. Then, we
implement two worker classes in VB.Net, one that uses DAO via Interop, and
then a few months from now, implement an ADO.Net worker class for SQL
Server that mimics the custom properties of Jet (this part is rather
straight forward, as we can do this using special tables.)

As I am exploring the topic, it seems that I''m going to have to make my
own collection classes (for the DAO recordset object, for example) and
pass those back to the app, essentially caching the DAO data. Yuck. I can
see memory usage and performance going right to hell, not to mention the
unintended consequences of failing to correctly implement some aspect of
DAO.

If I had my druthers I''d start over with a clean slate and rearchitect
this app to give it some reasonable object oriented structure and take
advantage of all that .Net has to offer - that just ain''t gonna happen.

Are there any _sensible_ approaches to solving this problem?

Sean

肖恩，

|呸。我

|可以看到内存使用和性能正常下去，更不用说

|无法正确实施一些的意外后果

| DAO的一个方面。

您将简单地实现代理类，根据我的经验，简单地说

代理类不会对内存使用或性能产生负面影响。

看到你想要使用DAO或ADO.NET，我会推荐一个

适配器模式。如果你有一个基类定义了适配器的接口，那么DAO& ADO.NET具体类定义了接口的

实现...


|如果我有我的druthers我会从一个干净的石板重新开始并重新构建

|这个应用程序给它一些合理的面向对象的结构，并采取

|所有这一切的优势.Net必须提供 - 这不会发生。

你仍然可以做到这一点&支持DAO和amp; SQL Server。您可以定义一个

域模型&然后定义2个特定的数据映射器：一个数据映射器确实是
SqlClient，一个是DAO。 （我为我的数据映射器定义了一个基类，以便最大限度地减少耦合）。

http://www.martinfowler.com/eaaCatalog/domainModel.html

http://www.martinfowler.com/eaaCatalog/dataMapper.html


如果正确定义数据映射器的基类，则应该能够引入对Oracle，AS / 400或任何其他数据源的支持（例如

作为Xml文件）。


除了/而不是域模型&您可以使用数据映射器模式
也使用表格模块&表数据网关模式。

http：// www .martinfowler.com / eaaCatalog / tableModule.html
http://www.martinfowler.com/eaaCatal...taGateway.html

|我的遗留VB6应用程序在很大程度上依赖于DAO，尤其是因为它是
|与数据库对象的自定义属性有关。这些定制

|据我所知，属性是不能用SQL Server实现的，

|我们需要在不久的将来迁移到它。

SQL Server 2000完全支持数据库对象的自定义属性。查询

扩展属性在BOL中。

http://www.microsoft.com/sql/techinf...properties.asp
http://msdn.microsoft.com/library/de...l/sql02a10。 asp


希望这会有所帮助

Jay

" Sean Kirkpatrick" < NA ********** @ community.nospam>在消息中写道

新闻：％2 **************** @ TK2MSFTNGP09.phx.gbl ...

| I有一个非常难看的问题，我需要一些真诚的指导。

|

|我的遗留VB6应用程序在很大程度上依赖于DAO，尤其是因为它是
|与数据库对象的自定义属性有关。这些定制

|据我所知，属性是不能用SQL Server实现的，

|我们需要在不久的将来迁移到它们。

|

|我的老板，公司的老板，要求我们提供一个

|过渡计划最小化（他真的不需要）代码更改为

|现有应用程序（超过8000个客户端使用）。它也是

|要求我们向所有

|提供100％向后兼容性现有的安装基础，所以我们永远无法放弃支持

| Jet DBs。 （是的，从来没有很长时间，但他仍然支持他的DOS

| 18年前的产品！）

|

|他想要的解决方案是我们创建一组VB.Net接口类

|它提供了与现有代码库相似的DAO接口。然后，我们

|在VB.Net中实现两个工作类，一个通过Interop使用DAO，

|然后几个月后，为

|实现一个ADO.Net工作类模仿Jet的自定义属性的SQL Server（这部分是相当的

|直接，因为我们可以使用特殊的表格来完成这个。）

|

|当我正在探索这个话题时，似乎我将不得不让我的

|自己的集合类（例如DAO记录集对象）和

|将这些传递给应用程序，基本上缓存DAO数据。呸。我

|可以看到内存使用和性能正常下去，更不用说

|无法正确实施一些的意外后果

| DAO方面。

|

|如果我有我的druthers我会从一个干净的石板重新开始并重新构建

|这个应用程序给它一些合理的面向对象的结构，并采取

|所有.Net必须提供的优势 - 这是不会发生的。

|

|是否有任何_sensible_方法来解决这个问题？

|

| Sean

Sean,
| Yuck. I
| can see memory usage and performance going right to hell, not to mention
| the unintended consequences of failing to correctly implement some
| aspect of DAO.
You would be implementing simply Proxy classes, in my experience simply
Proxy classes do not have adverse effects on memory usage or performance.
Seeing as you want to work with either DAO or ADO.NET, I would recommend an
Adapter pattern. Where you have a base class that defines the interface for
the Adapter, then DAO & ADO.NET concrete classes that define the
implementation of the interface...

| If I had my druthers I''d start over with a clean slate and rearchitect
| this app to give it some reasonable object oriented structure and take
| advantage of all that .Net has to offer - that just ain''t gonna happen.
You can still do this & support both DAO & SQL Server. You could define a
Domain Model & then define 2 specific Data Mappers: one Data Mapper does
SqlClient and one does DAO. (I define a base classes for my Data Mappers to
minimize coupling).

http://www.martinfowler.com/eaaCatalog/domainModel.html

http://www.martinfowler.com/eaaCatalog/dataMapper.html

If you define the base class for your Data Mappers correctly, you should be
able to introduce support for Oracle, AS/400 or any other datasource (such
as an Xml File).

In addition to/instead of the Domain Model & Data Mapper patterns you could
also use the Table Module & Table Data Gateway patterns.

http://www.martinfowler.com/eaaCatalog/tableModule.html

http://www.martinfowler.com/eaaCatal...taGateway.html
| My legacy VB6 application depends heavily on DAO, especially as it
| relates to custom properties on database objects. These custom
| properties are, as I understand it, not avabilable with SQL Server,
| which we need to migrate to in the not too distant future.
SQL Server 2000 fully support custom properties on database objects. Lookup
"Extended Properties" in the BOL.

http://www.microsoft.com/sql/techinf...properties.asp

http://msdn.microsoft.com/library/de...l/sql02a10.asp

Hope this helps
Jay
"Sean Kirkpatrick" <na**********@community.nospam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
|I have a very ugly problem and I need some sincere guidance.
|
| My legacy VB6 application depends heavily on DAO, especially as it
| relates to custom properties on database objects. These custom
| properties are, as I understand it, not avabilable with SQL Server,
| which we need to migrate to in the not too distant future.
|
| My boss, the owner of the company, requires that we provide for a
| transition plan that minimizes (he really wants none) code changes to
| the existing app (which is in use by over 8000 clients). It is also
| required that we provide 100% backward compatibility with all of the
| existing installed base, so we will never be able to abandon support for
| Jet DBs. (Yes, never is a long time, but he still supports his DOS
| product of 18 years ago!)
|
| His desired solution is that we create a set of VB.Net interface classes
| that presents a DAO like interface to the existing codebase. Then, we
| implement two worker classes in VB.Net, one that uses DAO via Interop,
| and then a few months from now, implement an ADO.Net worker class for
| SQL Server that mimics the custom properties of Jet (this part is rather
| straight forward, as we can do this using special tables.)
|
| As I am exploring the topic, it seems that I''m going to have to make my
| own collection classes (for the DAO recordset object, for example) and
| pass those back to the app, essentially caching the DAO data. Yuck. I
| can see memory usage and performance going right to hell, not to mention
| the unintended consequences of failing to correctly implement some
| aspect of DAO.
|
| If I had my druthers I''d start over with a clean slate and rearchitect
| this app to give it some reasonable object oriented structure and take
| advantage of all that .Net has to offer - that just ain''t gonna happen.
|
| Are there any _sensible_ approaches to solving this problem?
|
| Sean

On Tue，2005年7月19日10:49:36 -0700，Sean Kirkpatrick< na ********** @ community.nospam>写道：

$ b $b¤我有一个非常难看的问题，我需要一些真诚的指导。
$ b $b¤
$ b $b¤我的遗留VB6应用程序很大程度上依赖于DAO，尤其是因为它与数据库对象的自定义属性有关。根据我的理解，这些自定义
$ b $b¤属性不适用于SQL Server，我们需要在不久的将来迁移到这些属性。
$ b $b¤
$ b $b¤我的老板，公司的老板，要求我们提供最小化（他真的不需要）代码的过渡计划更改为现金应用程序（超过8000个客户端正在使用）。它还要求我们提供100％向后兼容所有现有已安装的基础，因此我们永远无法放弃对
$ b $b¤JetDBs。 （是的，从来没有很长时间，但他仍然支持18年前他的DOS
$ b $b¤产品！）
$ b $b¤
$ b $b¤他的我们想要的解决方案是创建一组VB.Net接口类，它们提供了一个类似现有代码库的DAO接口。然后，我们
$ b $b¤在VB.Net中实现两个工人类，一个通过Interop使用DAO，
$ b $b¤然后几个月后实现一个ADO.Net

的工人类¤模仿Jet的自定义属性的SQL Server（这部分是直接的，因为我们可以使用特殊的表来实现这一点。） /> $ b $b¤
$ b $b¤当我正在探索这个话题时，似乎我将不得不制作我的
$ b $b¤自己的收藏课程（例如，DAO记录集对象和
$ b $b¤将这些对象传递给应用程序，基本上是缓存DAO数据。呸。我可以看到内存使用情况和性能下降到地狱，更别提
$ b $b¤未能正确实施的意外后果

¤方面的DAO。
$ b $b¤
$ b $b¤如果我有我的druthers我会从一个干净的石板重新开始并重新构建
$ b $b¤这个应用程序给它一些合理的面向对象的结构，并采取.Net提供的所有优点的优势 - 这是不会发生的。
$ b $b¤
$ b $b¤是否有任何_sensible_方法来解决这个问题？


我看到尝试强加DAO接口的几个问题，其主要原因是

当与ADO.NET集成时，架构是完全不同的，这是一个很大的麻烦。

数据库对象或SQL Server。


当你或许可以使用底层的DAO Recordset，它不会直接转换为

ADO.NET。那将是一个互相绊脚石。关于开发一个模仿DAO的定制界面，DAO的设计方式与ADO.NET不同。即使是微软也会为.NET开发一个原生的DAO接口程序集。


您还必须考虑DAO的设计是通过持久连接来运行的br />
环境，通常使用基于文件的数据库，而ADO.NET的连接通常仅在数据库更新或查询期间可用。如果您正在使用Access数据库，这可能与当前架构非常不同。


就个人而言，因为您不仅要迁移到另一个开发产品，但也从基于服务器数据库的文件
，我会放弃尝试模仿.NET中的DAO接口的概念。

Paul

~~~~

Microsoft MVP（Visual Basic）

On Tue, 19 Jul 2005 10:49:36 -0700, Sean Kirkpatrick <na**********@community.nospam> wrote:

¤ I have a very ugly problem and I need some sincere guidance.
¤
¤ My legacy VB6 application depends heavily on DAO, especially as it
¤ relates to custom properties on database objects. These custom
¤ properties are, as I understand it, not avabilable with SQL Server,
¤ which we need to migrate to in the not too distant future.
¤
¤ My boss, the owner of the company, requires that we provide for a
¤ transition plan that minimizes (he really wants none) code changes to
¤ the existing app (which is in use by over 8000 clients). It is also
¤ required that we provide 100% backward compatibility with all of the
¤ existing installed base, so we will never be able to abandon support for
¤ Jet DBs. (Yes, never is a long time, but he still supports his DOS
¤ product of 18 years ago!)
¤
¤ His desired solution is that we create a set of VB.Net interface classes
¤ that presents a DAO like interface to the existing codebase. Then, we
¤ implement two worker classes in VB.Net, one that uses DAO via Interop,
¤ and then a few months from now, implement an ADO.Net worker class for
¤ SQL Server that mimics the custom properties of Jet (this part is rather
¤ straight forward, as we can do this using special tables.)
¤
¤ As I am exploring the topic, it seems that I''m going to have to make my
¤ own collection classes (for the DAO recordset object, for example) and
¤ pass those back to the app, essentially caching the DAO data. Yuck. I
¤ can see memory usage and performance going right to hell, not to mention
¤ the unintended consequences of failing to correctly implement some
¤ aspect of DAO.
¤
¤ If I had my druthers I''d start over with a clean slate and rearchitect
¤ this app to give it some reasonable object oriented structure and take
¤ advantage of all that .Net has to offer - that just ain''t gonna happen.
¤
¤ Are there any _sensible_ approaches to solving this problem?

I see several problems with attempting to impose a DAO interface, the primary of which would be that
the architecture is sufficiently different to cause a major headache when integrating with ADO.NET
database objects or SQL Server.

While you may be able to work with an underlying DAO Recordset, it doesn''t translate directly to
ADO.NET. That will be an interop stumbling block. With respect to developing a custom interface that
mimics DAO, once again, the way in which DAO was designed to function is different than ADO.NET. Not
even Microsoft would develop a native DAO interface assembly for .NET.

You also have to consider that DAO was designed to operate through a persistently connected
environment, typically with a file based database, while ADO.NET''s connections are generally
available only for the duration of the database update or query. This could be very different than
your current architecture if you''re using an Access database.

Personally, since you''re not only migrating to another development product but also from a file
based to server database, I would abandon the notion of trying to mimic the DAO interface in .NET.
Paul
~~~~
Microsoft MVP (Visual Basic)

这篇关于包装DAO，无论好坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！