我在这里寻找指针和信息，我将制作此CW，因为我怀疑它没有一个正确的答案。这是针对C#的，因此下面将对Linq进行一些引用。对于长篇文章，我也表示歉意。让我在这里总结问题，然后是完整的问题。
简介:在UI/BLL/DAL/DB 4层应用程序中，如何更改用户界面以显示更多列(例如在网格中)，避免泄漏到业务逻辑层和数据访问层，获取要显示的数据(假设它已经存在于数据库中)。
让我们假设一个具有3(4)层的分层应用程序:
在这种情况下，DAL负责构造SQL语句并针对数据库执行它们，并返回数据。
唯一“正确地”构造这样的层以便始终执行“select *”的方法是吗？对我来说，这是一个很大的禁忌，但让我解释一下为什么我想知道。
假设我要在我的UI中显示所有拥有活跃就业记录的员工。 “事件”是指从头到尾的就业记录包含今天(甚至可能是我可以在用户界面中设置的日期)。
在这种情况下，假设我想向所有这些人发送电子邮件，因此BLL中有一些代码可以确保我尚未向同一个人发送电子邮件，等等。
对于BLL，它需要最少的数据量。也许它调用数据访问层以获取在职员工的列表，然后调用以获取其已发送的电子邮件的列表。然后加入这些并构建一个新列表。也许可以在数据访问层的帮助下完成此操作，这并不重要。
重要的是，对于业务层来说，实际上并不需要太多数据。也许只需要两个列表的每个员工的唯一标识符都可以匹配，然后说:“这些是事件的唯一标识符，您还没有发送电子邮件到”。然后，我是否构造了DAL代码，该DAL代码构造了仅检索业务层所需内容的SQL语句？ IE。只是“从员工那里选择ID ...”？
我该如何处理用户界面？对于用户而言，最好包括更多信息，这取决于我为什么要发送电子邮件。例如，我可能想包括一些基本的联系信息，他们工作的部门或经理的姓名等，而不是说我至少要显示姓名和电子邮件地址信息。
UI如何获取该数据？是否更改DAL以确保将足够的数据返回给UI？我是否更改BLL以确保它为UI返回足够的数据？如果从DAL返回到BLL的对象或数据结构也可以发送到UI，则也许BLL不需要太多更改，但是UI的要求会影响超出其应与之通信的层的范围。 。而且，如果两个世界在不同的数据结构上运行，则可能必须对两者进行更改。
然后，当更改UI时，通过添加更多列以进一步帮助用户，我将/应该去多深的时间才能更改UI？ (假设数据已经存在于数据库中，那么在那里不需要进行任何更改。)
提出的一个建议是使用Linq-To-SQL和IQueryable，这样，如果DAL处理什么(如哪种数据类型)以及为什么(如WHERE子句)返回IQueryable，则BLL可以可能会将这些返回给UI，然后可以构造一个Linq查询来检索所需的数据。然后，用户界面代码可以拉入所需的列。这将是可行的，因为使用IQuerables，UI最终将实际执行查询，然后可以使用“选择new {X，Y，Z}”来指定所需的内容，并在必要时甚至加入其他表。
在我看来这很困惑。即使UI隐藏在Linq前端的后面，UI也会执行SQL代码本身。
但是，为此，不允许BLL或DAL关闭数据库连接，并且在IoC类型的环境中，DAL服务的处理时间可能比UI代码想要的要早一些，因此Linq查询可能只会以“无法访问已处置的对象”为异常(exception)而结束。
所以我在寻找指针。我们有多远？您如何处理？我认为，对UI的更改将通过BLL泄漏到DAL中，这是一个非常糟糕的解决方案，但是现在看来，我们不能做得更好。
请告诉我我们有多愚蠢，并证明我错了？
并请注意，这是一个旧系统。更改数据库架构已经多年了，因此使用ORM对象的解决方案实际上相当于“select *”的选择实际上并不是一个选择。我们有一些大表，我们希望避免拉近整个图层列表。
最佳答案
使用作为UI使用案例的 View 模型(或数据传输对象)的概念。获取这些对象将是BLL的工作，如果数据不完整，则请求其他数据(我们称为模型)。然后，BLL可以对要返回的 View 模型做出正确的决定。不要让您的模型(数据)细节渗透到UI中。
UI <-- (viewmodel) ---> BLL <-- (model) --> Peristence/Data layers
这种解耦可以更好地扩展您的应用程序。我认为持久性独立性自然不属于这种方法，因为可以通过使用linq2ql或其他orm技术在BLL中灵活地完成 View 模型的构造和规范。
关于c# - 不使用ORM的N层数据库应用程序，UI如何指定需要显示的数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1524367/