我们正在为我们的ERP系统编写一些支持应用程序（相当小）。
因此，直到现在我感觉我正在使用数据访问层来实现2个角色：业务层和数据访问层。
如果我需要，我无法决定要移动到单独的图层。我已经读过某个地方，知道何时进行分层是智慧，知道模式只是知识。我没有足够的金额。
所以我需要一些帮助才能确定是什么。
我当前的DAL处理获取数据并在其上应用基本逻辑。例如，有像
这样的方法 GetProductAvailabilitybyItem
GetProductAvailabilitybyLot
等
如果我需要将它们分开，我必须做什么？
我头脑中的另一个问题是，为了规范化我的DAL并使其每次返回不同的实体（通过一个通用的get方法），我将不得不使用DataTable作为返回类型。目前我使用List<PalletRecord>之类的东西作为返回类型。
我觉得我的应用程序非常小，难以辨别这2层。（
我的基本需求是构建可以被多个前端（网页，WinForms，WPF等）使用的东西。
附加示例：
让我们谈谈一些条形码。我需要检查获取的批次记录是否有效。我在DAL中获取记录并生成一个在业务层中返回bool的方法？
然后我可以从任何演示文稿中调用bool方法，以检查文本框是否包含有效批次？
这是非常简化的逻辑吗？
答案 0 :(得分：2)
鉴于您正在处理非常小的应用程序，为什么不只是让ORM为您提供所有数据访问权限而只是担心业务层？
这样你就不必担心处理DataTable，将数据映射到对象等等。开发速度更快，您可以减少代码库的大小。
例如，NHibernate或Microsoft的Entity Framework
现在，如果您要向外部消费者提供数据（您正在实施服务），您可能需要创建一组单独的DTOs，而不是尝试发送您的实际模型实体。
答案 1 :(得分：2)
根据您的描述，当应用程序仍然很小时，您当然应该立即分离两个层。当您只是访问和显示数据时，您可能会觉得BL是无用的，但是随着时间的推移，您会发现需要修改，转换或操作数据，例如从不同的表创建坐标对象，或者更新不同的表。来自用户的单一行动。
您提供的示例有助于支持这一想法，尽管已经非常简化。
Pablo的回答确实提供了一些很好的设计理念：你绝对应该使用ORM来简化你的DAL并保持它非常薄。我发现NHibernate and Fluent在这方面做得很好。您可以使用BL来协调使用数据访问对象的访问。
答案 2 :(得分：1)
我不是nTire架构的忠实粉丝，并且有充分的理由。
这种架构的主要目标是
然而，在这样做的同时，您还会做出一些牺牲，例如放弃提供者特定的优化等。
我的建议是，你可以使用两层架构，即。数据访问和业务逻辑层以及GUI或表示层。它仍然允许您拥有不同平台的通用代码，同时可以避免意大利面条代码。