标签: business-logic

例如,帐户1 - >*用户 - > 1身份验证 1帐户有多个用户,每个用户将拥有1个身份验证

我来自java背景,所以我通常做的是

1. 将这些类定义为java bean(即,只是getter和setter,没有附加逻辑)
2. 创建AccountManager ejb类,定义create_account方法(带1个帐号,用户列表)
3. 准备Web层中的数据,然后将数据传递到AccountManager ejb,例如: accountManager.createAccount(account, userList)

但是在django中,框架主张将域逻辑放入模型类(行级)或关联的管理器类(表级),这使得事情有点尴尬.是的,这是好的,如果你的逻辑是只涉及一个表,但在实际应用中,通常每一步都会涉及多个不同的表,甚至数据库,所以我应该在这种情况下怎么办？

将逻辑放入View中？我认为这根本不是好的做法.甚至覆盖模型类中的save方法,使用**kwargs传入额外的数据？然后后端会破裂.

我希望这说明我对业务逻辑放在django应用程序中的位置感到困惑.

我们试图在mvvm中弄清楚在业务逻辑或模型中进行验证的验证.我在业务逻辑中实现了异常类型的验证 - 可以在这里找到简化的图表:

如果我们有很多输入彼此独立,那么没有问题,抛出异常,文本框会捕获一个标记,它为每个错误的输入设置了红色边框.但是,当我们有依赖值时,我们就遇到了麻烦.例如

• 模型中的Value1和Value2必须不一样,所以我们在每个寻找equals值的函数中都有一个validate函数,如果发生这种情况则抛出异常

• 现在,如果我们将Value1设置为0而将Value2设置为1,一切都很好

• Value1在GUI中设置为1 - >这个被标记为红色,因为未触发其他值的验证,因此GUI中的Value2未标记为错误

• 在GUI中将Value2设置为2,现在我们已达到有效状态,但只有Value2得到验证,因此Value1仍被标记为有错

有没有一个共同的模式来解决这个问题？我们不希望在两个文本框之间的GUI中引入依赖关系,因为此逻辑应仅存在于业务逻辑层中.

除了通过异常实现验证之外,还可以实现IDataErrorInfo接口,但问题仍然存在,没有办法强制依赖值再次验证它们的值,至少没有我能看到:)

任何帮助表示赞赏

欢呼,曼尼

[清理,删除不必要的步骤]

15.11.2010 - 第2部分

好的,在这里重新思考,我们将继续使用businesslogic层.这是我们当前计划的配置: (图像在这里缩小了一点,请在单独的窗口打开它以完整尺寸显示)一切都或多或少清晰,除了如果数据模型如何通知不同编辑器的所有视图模型/模型克隆在业务逻辑下变了.一种方法是跟踪创建它们的业务逻辑中的克隆模型.使用业务逻辑commit()更改数据模型时,可以向所有其他已注册的模型克隆通知更改并进一步传播它们.或者,业务逻辑可以发布所有视图模型订阅的事件,以便他们也能获得更改 - 任何人都可以给我一个提示更好的提示吗？

再次感谢您的帮助,抱歉,我是如此精神错乱;)

在单独的数据访问和业务逻辑层中,我可以在业务层中使用Entity框架类吗？

编辑:我认为我将来不需要从我的业务逻辑中交换出数据访问层(即将是SQL Server),但是我将用于UI层.因此,问题更多的是在业务层中为我使用EF类有什么主要问题吗？好像管道代码会少一些.

处理复杂业务逻辑的好方法是什么,从一开始就需要许多嵌套的if语句？

例:

优惠券.可能:

1a)价值折扣
1b)百分比折扣

2a)正常折扣
2b)累进折扣

3a)需要访问优惠券
3b)不需要访问优惠券

4a)仅适用于已经购买的客户
4b)适用于任何客户

5a)仅从国家(X,Y,...)应用于客户

这要求代码更复杂,然后:

if (discount.isPercentage) {
    if (discount.isNormal) {
        if (discount.requiresAccessCoupon) {
        } else {
        }
    } else if (discount.isProgressive) {
        if (discount.requiresAccessCoupon) {
        } else {
        }
    }
} else if (discount.isValue) {
    if (discount.isNormal) {
        if (discount.requiresAccessCoupon) {
        } else {
        }
    } else if (discount.isProgressive) {
        if (discount.requiresAccessCoupon) {
        } else {
        }
    }
} else if (discount.isXXX) {
    if (discount.isNormal) {
    } else if (discount.isProgressive) { …

有没有人有任何关于保持我的GUI类逻辑的建议？我尝试使用良好的类设计并保持尽可能多的分离,但我的Form类通常最终会混入比我想要的更多的非UI内容,并且它往往使维护变得非常痛苦.

(Visual Studio 2008 Professional,C#,Windows应用程序).

非常感谢.

我需要获取content某个meta标签的属性值.

var someContent = $("meta[name=someKindOfId]").attr("content");

我通常是这样做的.出于商业原因,someKindOfId可能会somekindofid.它也可能是其他案例组合.我不知道.

搜索此元标记的最佳方法是什么？添加id或其他标识符是不可能的.

假设您有一个可以跨多个对象执行某些操作的业务逻辑方法.也许您想要为从列表中选择的每个人拨打一个抽奖号码选择网络服务.在Java中,代码可能如下所示:

Set<Person> selectedPeople = ... // fetch list of people
for ( Person person : selectedPeople ) {
    String lotteryNumber = callLotteryNumberWebService( person );
    // ...
}

注意,彩票号码网络服务可能具有副作用,例如记录该人已请求彩票号码(可能对他们的账户收费),因此即使一个人的网络服务呼叫失败,其他人也可能成功.这些信息(彩票号码)需要反馈到更高级别(视图).

如果这是发生单个操作的情况,则业务逻辑方法可以返回单个值(例如,抽奖号码)或抛出异常以及失败的任何细节.但对于批量操作,一些操作可能会成功,一些操作可能会失败.

这似乎是许多应用程序中会出现的一种问题,应该有一种干净的方法来处理它.那么,将这种类型的信息从业务逻辑层反馈到应用程序中的另一层(如视图)的最佳方法是什么,最好是以可以重用于不同类型的数据和操作的通用方式？

我是一个ASP.NET MVC开发人员,刚开始我的第一个关于rails的大项目,但我很困惑,因为我把业务逻辑放在哪里？在ASP.NET上我创建了一个包含处理业务逻辑的服务(域驱动设计)的库,我听说rails使用了胖模型瘦控制器的概念,但我在ASP.NET中有一些项目,它们将所有逻辑添加到控制器会造成很大的混乱,还有其他方法吗？

我对MVC模式不太熟悉.你能告诉我以下哪三种控制器动作更好吗？谢谢 :)

(1)查询在行动:

public ActionResult List()
{
   var query = repository.Query().Where(it => it.IsHandled).OrderBy(it => it.Id);
   // ...
}

(2)有服务查询:

public ActionResult List() 
{
    var items = service.GetHandledItemsOrderById();
    // ...
}

(3)通过行动订购:

public ActionResult List()
{
    var items = service.GetHandledItems().OrderBy(it => it.Id);
    // ...
}

如果我们选择(1),那么我们在控制器中有太多的业务逻辑？

如果我们选择(2),可能会有很多服务方法GetXXXByYYY().

如果我们选择(3),为什么我们封装Where(it => it.IsHandled)但不是
OrderBy(it => it.Id.

有任何想法吗？

我目前正在为多渠道商务系统设计架构,该系统将具有针对设备和频道(用户类型和位置)定制的多个不同的前端演示.我面临的挑战是如何最好地确保我们以减少前端表示层重复的方式开发核心商务平台.

以下是我们需要支持的不同前端演示层的示例:

• 面向消费者的传统桌面网站
• 针对消费者的移动优化网站
• 适用于消费者的原生移动应用程序(iOS/Android)
• 客户支持中心的客户支持中心网站
• 基于Instore信息亭的网站,供消费者在实体店购物
• 其他(微型网站和其他利用各种技术,如Angular,PHP,.NET等)

现在,我了解了分层体系结构(表示,业务,数据层)和常见设计模式的最佳实践,以解决单个应用程序(如MVC,验证器,拦截器)中的前端挑战.但是,这些原则都没有解释在面对支持多个前端时如何以及在何处最佳地封装您的表示特定业务逻辑.

所以,我的问题是在开发这样一个系统时要遵循一些好的做法和原则,以确保每个前端应用程序不会重复前端业务逻辑？

我过去使用不同的方法开发了许多具有这种要求的应用程序......其中一些工作得相当好,一些工作效果不是很好.但每次我觉得我正在为一个普通问题发明一个解决方案,并且必须有一些最好的实践和原则来利用.

我要问的具体挑战的一个简单例子

我们所有的前端应用程序都必须支持注册新客户帐户的能力.登记表格将包含电子邮件,密码和客户地址信息(街道,城市,邮编等).提交表单时,在系统中创建帐户并向用户发送验证电子邮件之前,需要进行某些简单且非平凡的验证.例如:

• 电子邮件地址模式验证规则
• 确保系统中不存在电子邮件地址
• 密码复杂性规则
• 地址验证(通过第三方地址验证/标准化系统)

在大多数情况下,需要在所有前端系统中强制执行这些验证规则,尽管每个前端的注册流可能略有不同,并且可能只包含字段的子集.那么,为前端提供API的一些好的做法是什么,这样每个前端都不会复制正确验证和处理注册所需的各个步骤？例如,如果我们决定更改密码复杂性规则或地址验证规则等 - 我们是否可以最好地设计系统,以便我们不必走出去并使用这个新的验证逻辑更改所有各种前端应用程序.

为了清楚起见,我并不关心在哪里放置所有前端共享的核心业务逻辑(即帐户创建服务,地址验证服务,帐户查找服务等).这些模式通常在博客,书籍和论坛中讨论.我的问题与业务逻辑特别相关,业务逻辑通常与表示层紧密耦合.一些问题总是浮现在我的脑海中.

• 我们是否应该提供支持所有前端操作的表示服务层,包括表单验证和通过Web服务处理？或者每个前端是否应该拥有它的表示逻辑,因为"没有两个前端相似"？
• 如果我们确实创建了一个表示服务层,我们如何提供解决每个前端细微差别的服务？我们是否为每个前端提供不同的服务/端点,或者只是提供每个前端在调用我们的服务时传递的不同"上下文"？
• 此表示服务层是否控制错误消息传递并向每个前端返回适当的上下文感知消息,或者我们是否应该传回错误代码并让前端拥有此消息？
• 等等