什么在 3 层架构中去哪里
本文关键字:什么 | 更新日期: 2023-09-27 18:31:29
最近,我们的教授说,我们的表示层应该主要由方法调用组成,我们的大部分代码应该在业务对象和数据访问层完成。 我的问题是这通常包括用户输入的代码吗? 我的意思是这个;我有一个由多个文本框组成的表单,以便用户可以为不同的事物输入值。 然后,用户单击一个按钮,信息将保存在数据库中。
按钮偶数方法如下所示:
//event handler for data input
public static void btnEnterAbRipperXInfo_Click(object sender, EventArgs e)
{
//convert text box data into int datatype and assign to variable
inAndouts = int.Parse(txtInAndOuts.Text);
forwardBicycles = int.Parse(txtForwardBicycles.Text);
reverseBicycles = int.Parse(txtReverseBicycles.Text);
crunchyFrog = int.Parse(txtCrunchyFrog.Text);
crossLegWideLegSitups = int.Parse(txtCrossLegWideLegSitups.Text);
fiferScissors = int.Parse(txtFiferScissors.Text);
hipRockNRaise = int.Parse(txtHipRockNRaise.Text);
pulseUpsHeelsToHeaven = int.Parse(txtPulseUpsHeelsToHeaven.Text);
vUpRollUpCombos = int.Parse(txtVUpRollUpCombos.Text);
obliqueVUps = int.Parse(txtObliqueVUps.Text);
legClimbs = int.Parse(txtLegClimbs.Text);
masonTwists = int.Parse(txtMasonTwists.Text);
}
上述按钮事件方法中的代码是否应该实际进入业务对象或数据访问类,而不是表示层类?
这不是家庭作业。 我正在编程课之外为我的儿子创建一个 90 天的锻炼计划。 我也可以将其用作毕业时的作品集,因此,我想确保我遵循标准做法。
代码从 UI 读取值。
此代码只能在 UI 层中,因为业务层无法访问 UI。
通常在 UI 层或表示层中,您可以从控件中获取值(就像您现在所做的那样)。然后使用所有这些值调用业务逻辑方法。类似的东西
BAL.ProcessRequest(arg1,arg2,.....);
现在,如果您有一些与这些输入相关的业务规则,则可以在业务逻辑中执行。例如,如果您正在传递产品及其订购数量,并且想要根据某些业务规则计算这些产品的折扣,则在业务层中执行折扣计算。
之后,当您即将提交到数据库时,您可以调用数据访问层。像这样:
DAL.SaveData(arg1,arg2,...);
具有单独层的原因基本上是松散地耦合应用程序。例如,如果您决定更改铺设不足的数据库,则只需要更改数据访问层,而不需要更改业务层或表示层。
假设您要将UI/表示层从 Web 应用程序更改为桌面应用程序,那么如果只能在表示层进行更改。业务层和数据访问层将保持不变。如果您正在考虑将文本框控件传递给业务层,那么您的应用程序将被耦合(UI/Presentatioin 层将与业务层耦合)。
这是一篇解释三层架构的文章。
BOL 负责在进入 DAL(数据访问层)之前需要清理的特定业务检查/案例。 DAL 只是从 BOL 获取输入并将其向下传递到数据库。
如果文本框值不需要任何类型的业务逻辑,则可以将它们传递给 BOL,以便将它们自由地传递给 DAL。
从代码的外观来看,不需要检查/验证。 虽然这看起来是多余的,但为了与您的项目保持一致,您仍然可以将它们传递给 BOL。 从本质上讲,您的 BOL 不会根据这些值采取行动 - 它只会获取这些值并将其传递给 DAL。
不,这不适用于域或数据层对象。由于您直接与表示元素交互,因此这对于 UI 层来说很好。
现在,一旦您提取了这些值并将其解析为适当的类型,那么最好将该工作从 UI 层转移出去。
此外,应考虑使用 int.TryParse
转换值,因为如果在一次文本框中输入非数字值,表单将引发异常。