我们正在为我们的 ERP 系统编写一些支持应用程序(相当小)。
因此,到目前为止,我觉得我正在为 2 个角色使用数据访问层:业务层和数据访问层。
我无法决定必须将哪些内容移至单独的图层以及是否需要。我在某处读到,知道何时进行层分离是智慧,而了解模式只是知识。我的数量都不够。
所以我需要一些帮助来确定什么是什么。
我当前的 DAL 处理获取数据并在其上应用基本逻辑。例如有这样的方法
GetProductAvailabilitybyItem
GetProductAvailabilitybyLot
等等
如果我需要将它们分开,我必须做什么?
我脑子里的另一件事是,为了规范化我的 DAL 并让它每次都返回不同的实体(通过一种通用的 get 方法),我将不得不使用 DataTable
作为返回类型。目前我正在使用类似 List<PalletRecord>
的东西作为返回类型。
我觉得我的应用太小了,很难(而且可能没用)区分这两层。
我的基本需求是构建可以被多个前端(网页、WinForms、WPF 等)使用的东西。
附加示例:
让我们谈谈条形码。我需要检查获取的批处理记录是否有效。我在 DAL 中获取记录并在业务层生成一个返回 bool 的方法?
然后我可以从任何演示文稿中调用 bool 方法以检查文本框是否包含有效批处理?
这是不是逻辑极度简化了?
最佳答案
根据您的描述,当应用程序还很小时,您现在绝对应该将两层分开。当您只是访问和显示数据时,您可能会觉得 BL 毫无用处,但随着时间的推移,您会发现需要修改、转换或操作数据,例如从不同的表创建坐标对象,或更新不同的表来自用户的单个操作。
您提供的示例有助于支持这个想法,尽管非常简单。
Pablo 的回答确实也提供了一些好的设计思路:您绝对应该使用 ORM 来简化您的 DAL 并使其非常薄。我找到了 NHibernate and Fluent在这方面做得很好。您可以使用 BL 来协调使用数据访问对象的访问。
关于c# - 从数据访问层提取业务逻辑,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13781009/