问题标签 [business-logic]

我们维护一个拥有超过一百万行 COBOL 代码的系统。有人有关于如何迁移到 GUI（可能基于 Windows）而不丢失我们用 COBOL 编写的所有业务逻辑的建议吗？是的，一些业务逻辑隐藏在当前的用户界面中。

古老的问题。您应该将业务逻辑放在哪里，作为存储过程（或包）放在数据库中，还是放在应用程序/中间层？更重要的是，为什么？

假设数据库独立性不是目标。

您如何为您的客户地址数据建模以及您使用什么技术来确保数据质量？

诸如重复数据删除算法、重复匹配、确保包裹和发票实际上可以交付等等之类的东西？尤其是在处理多个国家客户的系统中。

我们计划重新设计、改进我们的 (C#) 应用程序架构。有人有一些框架、主页或书籍推荐吗？主要是业务逻辑。

（对不起我的英语）例如，在我的 DAL 中，我有一个 AuthorDB 对象，它有一个 Name 和一个 BookDB 对象，它有一个 Title 和一个 IdAuthor。

现在，如果我想显示所有书籍及其相应作者的姓名，我必须获取所有书籍的集合，并使用 IdAuthor 属性为每本书找到作者姓名。这会对数据库进行大量查询，显然可以使用简单的 JOIN。

我有哪些选择？创建一个包含作者姓名和书名的“自定义”对象？如果是这样，维护可能会变得很糟糕。

那么，有哪些选择呢？谢谢！

我即将进入设计商品交易应用程序的第一阶段。该应用程序的一个主要功能是获取和评估定价信息。这个市场的定价不是固定的。它通常是市场基准 +/- 溢价。例如：（A和B是市场基准）

• 价格 = A + 1 美元
• 价格 = A + .5(AB)

交易的最终价格是使用在约定时间内应用的定价公式计算的。例如; 最终价格可能是装载商品前一周和后一周的平均 A + 1 美元。

目前，交易者正在 Excel 中捕获此详细信息，这使他们能够灵活地设置所需的公式，但此信息从未进入我们的会计系统，并且电子表格未连接到市场基准的实时预测，使得价格预测成为手动和缓慢的任务。

我正在寻找关于我可以使用哪些工具/技术在应用程序中输入、存储和评估公式的输入。

我们将使用 SQL Server 或 Oracle 作为数据库，客户端平台尚未固定，但您可以假设 WinForms/WPF、ASP.NET 或 Java webapp。

我知道这是一个相当广泛的问题，但我们还远远不够，无法更具体地说明将使用哪些技术。

谢谢

几天前， Derik Whitaker 发表了一篇文章，这引起了我一段时间以来的好奇：业务逻辑是否应该存在于控制器中？

到目前为止，我看到的所有 ASP.NET MVC 演示都将存储库访问和业务逻辑放在控制器中。有些甚至还会在那里进行验证。这导致了相当大、臃肿的控制器。这真的是使用MVC框架的方式吗？看起来这最终会导致大量重复的代码和逻辑分布在不同的控制器上。

什么是 BPEL？我正在寻找一些 BPEL 用法的简单示例。维基百科页面不是太有启发性。BPEL 中的“Hello world”怎么样？BPEL 外壳？BPEL IDE？

我正在努力将我们的企业技术范式转变为敏捷开发。这是一个艰难的过程，但我们快到了！:)

我们有用于数据库管理的遗留系统（以前是 Access，现在移植到 .NET 和 MS SQL），我们正在为我们的未来愿景开发一个框架。我们希望尽可能多地迁移到网络。但我们希望将当前系统与“即将推出”的系统集成。我们不会重叠任务和功能。

我的愿景是将我们用户的所有联系信息移动到不同的数据库，将这些“配置文件”链接回 MS SQL 以获取他们的历史和会计信息。我们会将所有会计系统保留在桌面应用程序上，但我们将添加更多功能，这些功能将严重依赖于 Web，尤其是 Ruby on Rails。

我想问题是：为什么是 ESB？有没有一种方法可以创建 SOA，而无需对复杂的 ESB 系统进行狂热的操作。无论如何，整个想法是亲吻。是否可以以允许桌面/Web/移动作为接口的方式创建 SOA，将功能保留在业务逻辑上（当然，某些功能必须在接口上实现，但要保持在最低限度）。ESB 甚至符合敏捷哲学吗？我阅读和研究它们的次数越多，我就越不这么认为！：/

感谢您的输入！如果您需要我澄清，请提出几个问题，我会尽力做到这一点！:)