我觉得我可能会做一些愚蠢的事。
我有一个运行多年的Linq to SQL库，并在几个使用相同数据库的应用程序中使用它。虽然有很多我不太满意的事情，但我刚刚得到了一个新项目。我认为在应用程序和Linq to SQL库之间放置一个业务逻辑层会很有帮助。问题是我设计的越多，它看起来就越多，我只是想尝试实现看起来像Linq to SQL的东西。
例如，我决定应用程序应该只有一个业务逻辑入口点。因此，入口点（我称之为MCP）在系统中具有类的属性，并且此属性具有“列表”（可能是IQueryable），其包含来自相应表的所有对象。它开始发声，看起来很像Linq to SQL数据上下文...而且我觉得在每个现有对象周围都有一个额外的对象/访问器，只是为了隐藏“真实”对象而进行大量的额外输入。 / p>
因此，我有点害怕，我只是对我已经拥有的东西进行了糟糕的重新实施。
另一方面，我希望改善一切的运作方式。例如，确保对象具有一个逻辑责任，而不是它是一种访问系统中任何其他内容的方式。 （例如，CarCP可能有AddDriver（Person p）的方法，但Person不一定有返回CarCP的方法。）
所以也许最好有这个中间层，但我只是设计得很糟糕？
答案 0 :(得分：0)
我花了很多年时间试图取得类似的成就。我认识的程序员并不满足于遵循“三层”理念的结果。直到我退后一步看看我在做什么，我决定完全放弃这个方法。
首先，没有人向我展示了一个“商业逻辑”层，我认为“哦，这实际上非常好！”。他们似乎都有问题。我认为可能性不利于我们。
其次，任何不增加值的代码行都不应该存在，而且三层思想似乎需要大量的“包装”，它们没有任何好处，而且是纯粹的开销。
最后，如果你退后一点，那就这样想吧：
数据层和业务逻辑层似乎使开发人员可以轻松访问大量全局状态。这真的是我们想要的吗？我们认为分享国家是一个好主意吗？
更重要的是，共享状态与使用全局变量有相同的缺点吗？您不仅可以使用任何代码行来更改数据，还可以在多个应用程序中使用“DAL”，使数据比全局变量更加全局化。
它会导致各种各样的乐趣，试图弄清楚为什么最新版本的应用程序X导致在数据库行中更改布尔值，最终导致应用程序Y失效。
我暗示这种做法只是错误的做法。对不起，这不是能给你立竿见影的答案。
我想提出一些建议。您可以轻松找到哪些代码区域访问相同的数据，并将它们组合在同一个库中。如果这样做，您会发现数据访问，逻辑和UI组合在一起 - 与三层方法完全相反。