问题标签 [business-logic]

在定义 XSD 架构时使用属性组而不是属性有什么好处？

好的...所以我可以在其他地方声明它们并引用它们...

还有什么？

I know the basic ways to avoid the N+1 selects problem in Hibernate/NHibernate, but have run into a variant of the problem that I can't find a good solution to.

I have the following three entities mapped: Item, Category and Customer. An item is associated many-to-many to Category, and a Category is mapped many-to-one to Customer. So far, nothing special.

A standard query in my application is to get all the items for a given customer. I do this using the following criteria, trying to fetch the items' categories eagerly, to avoid N+1 selects when examining the items' Categories property:

However, this doesn't work, NHibernate still fetches the categories with one select per item later on.

What I believe is going on is that NHibernate knows that the result from the first query is filtered (on Customer), and that the categories returned by the query might not be complete, hence it later has to do a separate query to get the categories. (Is this assumption correct? It seems reasonable to me that NHibernate must work this way to ensure correct results.)

However, according to my business rules (or what you want to call them), an item can't belong to categories from more than one customer, so in reality I know the result from the first query is actually complete.

My question is: can I tell NHibernate about this business rule in any way? Is there another way to avoid N+1 selects in this type of situation (which seems pretty common)?

我正在尝试整理我的代码，我有许多项目都引用了我的服务层，即 DLL。这意味着当我分发一个新的服务层时，我必须上传一些通常相同的服务层..

当然，使用 ADD Reference 非常快，因为它的一个程序集与另一个程序集通信......

我想知道另一种方法的优缺点..

我可以使用 web 服务/wcf 来包装我的服务层，但这不是破坏对象..

那么速度呢，现在我的桌面应用程序需要调用 web 服务/wcf 而不是访问程序集引用？

我的服务层当然与我的数据层对话，而我的客户从不直接与数据层对话..

它是服务层的问题，这是我的业务逻辑在许多应用程序之间共享的地方。

桌面应用程序、2 个网站、2 个 wcf 项目（用作 Web 服务）

关于如何在不重复我的代码的情况下实现最快的场景的任何建议，这对我现在正在做的事情有影响，即

每个应用程序（桌面、网站、wcf）在同一个 DLL 上都有副本并有引用（在 vs 2008 中添加引用）..

想法？

我正在使用 Java 来创建 Web 应用程序。应用程序必须加载一个表单，该表单将其数据发送到调用长业务逻辑的 jsp。我需要 jsp 将返回一条消息，例如“感谢您使用我的服务，完成后会向您发送一封电子邮件。”

问题是，如果我会写这样的东西：

jsp 将运行很长时间，用户将不得不等待操作结束。此外，如果用户关闭浏览器，我不确定 jsp 是否会继续工作。

如何将长操作与 jsp 隔离，以便用户不必等待所有执行时间，以及如何使长操作执行不依赖于浏览器？

瑙尔

在我当前的项目中，业务逻辑是在存储过程（其中有 1000 多个）中实现的，现在他们希望随着业务的增长对其进行扩展。架构师已决定将业务逻辑移至应用层 (.net) 以提高性能和可扩展性。但他们并没有重新设计/重写任何东西。简而言之，从 SP 触发的相同 SQL 查询将从使用 ADO.Net 的 .net 函数触发。这怎么能产生任何性能？

据我所知，当我们需要独立于数据库或者有一些业务逻辑可以用 OOP 语言比 RDBMS 引擎更好地实现时，我们需要将业务逻辑移动到应用程序层（比如遍历层次结构或一些图像处理， ETC..）。其余的情况，如果没有复杂的业务逻辑需要实现，我认为还是把业务逻辑放在DB本身比较好，这样至少可以避免应用层和DB之间的网络延迟。

请让我知道你的看法。我是一名开发人员，在考虑一些架构决策时有点犹豫，请原谅我对这个主题的无知。

我有一个业务对象，它编译成一个 DLL，它为我的系统处理资格等概念的所有计算。该对象还通过围绕它的一些包装器处理与数据库的连接。

有没有办法获取这个 .NET DLL 并将其用作报告服务报告 (SSRS) 的数据源？我们不想在多个地方都有逻辑。

编辑
如何在 Web 应用程序本身的 Web 服务中公开功能并让报表连接到 Web 服务？以前有人做过吗？如果有帮助，我们正在将 asp.net MVC 用于我们的 Web 应用程序。

我已经使用 VisualStudio 集成测试环境进行了一些测试，它们通过调用 BLL 方法来模拟我的 Web 应用程序将执行的操作（它们只是 UI 层应该知道并与之交互的方法）......

因此，如果他们的行为是正确的——我的测试通过了——我为什么要像许多文献建议的那样为 DAL/存储过程等较低层编写测试？

In a perfect world you have the validation (verification) of inputs in the business logic layer, not in the presentation or persistence layer. In reality you can (or want) to place it anywhere.

Lets make a simple sample (web-application using a framework like JSF or ZK): A certain input field accepts 4 digits between 0001 and 0500.

1. You could use the constraint features of your web framework to do this. Convenient for user, no additional server load.

2. You could do it in business layer (eg java-ejb). Foolproof because all applications using the same ejb will use the same validation. Eventually not nice because you need to throw back error at user after evaluation. Needs roundtrip to and from server.

3. You could rely (partially) on the DB to fail if someone enter (via persistence layer) a non-digit value or a value with more than 4 digits. Ugly.

Resume: You would do it (redundant) in 1. and 2. (Make it nice for the user and make it consistent for all applications). (Plus the length of DB col would be 4 )

Now the QUESTION: How you document this validation ? Text document or an UML diagram ? In a way you have business logic in up to 3 locations. In complex systems this close to impossible to track and understand.

Real life scenario for above sample: You need to change from 4 to 5 digits. Without documentation you need to hunt for the locations where changes might be required.

Whats you experience ? Any tips or tools for this ?

cheers
Sven

可以说我有一个这样的枚举表：

我在订单上有一些商业规则

也许不是最好的例子。但关键是，如何使“p.ShippingType == 1”部分可读。当下一个人来维护此代码时，他必须找到生产数据库，并查询每个业务规则的表以了解它们的作用。

我考虑过在代码中创建一个枚举只是复制数据库中的数据，但这似乎也不是一个好的解决方案。

如果有一个像这样分层的业务应用程序，这是否是适当的分工：

数据访问

• 仅调用存储过程，将DTO的属性映射到哈希表，用于填充 ADO.NET 命令的参数集合。

• 仅参考 SqlDataClient 的程序集。

• 处理映射代码中的空白、null 和空的含义的重要逻辑，但其他情况下没有验证或其他特定于域的逻辑。

所谓的业务逻辑

• 将多个结果集拆分为单独的数据表，例如

  公共无效 ReturnNthRecordSetFromStoredProcFoo()

• 传递到数据集的数据访问，例如

  public void ReturnDataSet(string name){ return (new PersonController).GetAnotherDataSet(name);}

• 将 DataTable的一行映射到一个DTO

• 处理映射代码中空白、空值和空的含义的重要逻辑。
• 保存事务对象，尽管它专门用于包装单个存储过程调用。
• 没有对 SqlDataClient 的引用，所以它不能使用 SqlDataReaders 来填充 DTO
• 没有参考 System.Web.UI
• 授权规则，但除此之外没有特定于域的逻辑。

用户界面

• DTO 到 ASP.NET 表单的 2 路数据绑定。
• 控件属性的验证 - 通常不直接针对 DTO 进行验证
• 通过将 DataSet 绑定到网格来导航“集合”。实际上，尝试对集合进行任何操作都需要 UI 遍历 DataTables 中的 DataRows 并知道适当的列名是什么（通常只是与 DTO 有点相似）

所以最后的问题是——对于这个应用程序，数据访问层是否应该承担所谓的业务层的职责？ 除了额外组装带来的不便之外，这不是已经是两层（几乎是一层！）应用程序了吗？

附加信息：好的，我已经知道应用程序服务器将是一台机器，可能永远是一台机器，因为它是一个低用户数的 Intranet 应用程序。所以我知道不要设计物理上独立的应用程序层。此外，它可能只支持一个 UI，如果它需要支持 ASP.NET 以外的其他东西，它可能会被完全废弃——这是层/层的另一个经常引用的原因。