我们正在将应用程序从 Classic VB 迁移到 VB.Net 2008，我需要创建一个基本命名空间和业务层。我的方法是访问我们的顶级 BA，确定我们（固定收入）公司的共同领域，并尝试用尽可能多的泛型代码形成一个体面的继承模型。
每个人的经验如何？作为问题的第二部分，我们正在考虑将 Web Focus 整合到 OLAP 端，这将如何影响公司命名空间及其衍生产品的设计？
【问题讨论】：
标签： vb.net generics vb6 namespaces vb6-migration
我认为开始创建企业 .NET 框架的最佳方式是从当前企业项目中获取现有代码开始。通过与 BA 交谈而不为特定的具体项目编写代码从头开始构建框架可能会导致您在某些领域过度设计框架，而在其他领域完全错过一些必要的功能（同样，它可能会对您的框架施加人为限制无正当理由的客户）。
有关更完整的解释，请参阅 Fowler 在 Harvested Framework 和此 blog post 上的条目。
我不熟悉 Web Focus，但我猜它会以某种方式影响它，但是，如果您使用 Harvested Framework，那么您在构建的前几个应用程序中对它的使用将影响您的使用方式框架内的 Web Focus。
【讨论】：
Jereme 在框架上做到了这一点。我将简要提及一些关于命名空间的明显内容。
永远记住命名空间的用途——它提供了一个名称将存在的“空间”。特别是，它旨在提供一个足够小的空间，以便在该空间内创建名称的人不太可能产生重复或混淆的名称。
这只有在命名空间按照组织模式或领域知识组织时才有效。一个经常使用的简单示例是 Company.BusinessUnit.Application 的模式。该理论认为，在开发给定应用程序的一组开发人员中，名称重复的可能性较小。这不适用于大型应用程序，您可能希望根据层或区域进一步分解它。同样，业务部门太大，您需要将其分解。
但在所有情况下，您实际上是在尝试对大脑集进行分区，因为创建名称的是大脑。
【讨论】：
如果您的应用程序在 VB6（不是 VB3）下，那么我强烈建议您首先在 VB6 中重新设计类层次结构。这样做的原因是，在任何转换中，您都试图保留旧应用程序的行为。是延长项目时间来做这件事并同时进行重新设计。
通过首先在应用程序的原始语言中进行设计更改，您可以确保导致的任何错误都是由于设计而不是转换造成的。
在过去的 20 年里，我对我们的软件进行了 3 次重大转换； （DOS 到 VB3）（VB3 到 VB6 中的面向对象设计）和（VB6 到 VB.NET）。
最后，直接在 VB6 中进行设计，即可轻松移植到 VB.NET。诀窍是将特定的 VB6 API 和结构隐藏在接口后面（图形、打印等）>
我建议从上到下进行转换。首先将您的表单更改为调用 VB6 COM DLL 的 .NET。然后转换每一层，直到到达底部的 DLL。
同样，如果您尝试更改设计并为任何复杂的应用程序转换为另一种语言，您将加倍转换时间。
【讨论】：