.NET 基于数据的应用程序架构建议、意见、良好实践

Question

我想问一个关于在 .NET 中构建使用数据库数据的应用程序的问题。有许多技术和模式，我正在尝试将它们全部连接起来。

我正在使用本地数据库构建桌面应用程序，因此我选择了 SQLServer CE + WinForms，但我希望尽可能保持通用性。我不喜欢其他技术（Java 等），但如果那里有一些好的解决方案，那么欢迎您写它们。

我想请教您用于构建应用程序的建议、意见和良好做法。您会添加或删除任何列出的图层吗？你更喜欢什么技术？

以下是应用程序的基本层：

1) SQLServer CE/SQLServer/Oracle/IBM DB2
--------------------------------------------------
2) LINQ to SQL/Entity Framework/NHibernate/ADO.NET
--------------------------------------------------
3) Data Transfer Objects
--------------------------------------------------
4) DTO-to-BM/Data Access Objects
--------------------------------------------------
5) Business Model
--------------------------------------------------
6) MVP/MVC/MVVM/PM
--------------------------------------------------
7) WinForms/WPF/ASP.NET

1) 这是经典的关系数据库。那么第一个问题是是否使用存储过程和触发器？我将使用 SQLServer CE，所以我没有 SP，但我想知道 peaple 是赞成还是反对他们。对我来说，不将逻辑放入数据库似乎更容易（更可测试，更可验证）。业务规则将放置在业务层中 - 可能在某种“框架”中。

2) 这是数据库访问层。

3) DTO - 简单的 POCO。他们需要吗？

4) DTO 和 BM 之间的映射。手工编码、AutoMapper 还是继承？或者也许是 DAO - 用于访问从 BM 返回对象的数据库的抽象对象？

5) 构建业务模型的业务对象。我会把所有的业务规则和验证放在这里。但是需要这一层吗？或者你会把所有的业务都放在第 3 层吗？

6) 和 7) 使用 BM 构建 UI。

Answer 1

如果你想使用一些嵌入式 sql 数据库，你应该看看SQLite。它比 SQL CE 具有更多有用的功能，并且运行速度更快且没有问题。甚至更多，我建议您使用一些文档或对象数据库（例如db4o）。 IMO，它将大大简化您的 DAO 和代码。

1，我更喜欢使用 ORM，而且我很少使用存储过程和触发器，而且只在遗留应用程序中使用。处理 c# 代码并将所有内容集中在一个地方要容易得多。你的逻辑和业务规则是正确的。

2、我更喜欢使用 NHibernate 作为最成熟、最强大和可定制的框架。而且我还建议您查看NhProf（按照这个词，L2S 和 EF 存在相同的分析器）。

3&4，只需删除它，不必要的噪音和猴子工作。

2&5，将您的数据库模型用作 BusinessModel（使用 NHibernate 非常容易）。查看this 和this 文章。

6&7，对于 web，我选择带有 asp.net mvc 的 MVC，对于 WPF - MVVM。根据我的经验，当您没有遗留代码等限制时，不要使用 WinForms 和 Asp.Net。使用 Asp.Net Mvc 和 WPF 进行开发更加容易和有趣。并且有很多很酷且节省时间的框架 - MvcTurbine、MVC Contrib、SharpArchitecture for asp.net mvc 和 Caliburn、WPF Toolkit、Cinch、MVVM Light toolkit 和许多其他框架。

另外，我建议您查看以下文章和示例，它们可能会帮助您更好地设计应用程序：
http://nhforge.org/blogs/nhibernate/archive/2009/08/27/nhibernate-and-wpf-validations.aspx
http://nhforge.org/blogs/nhibernate/archive/2009/11/07/nhibernate-and-wpf-the-guywire.aspx
http://msdn.microsoft.com/en-us/magazine/ee819139.aspx
http://code.google.com/p/unhaddins/source/browse/#svn/trunk/Examples/uNHAddIns.Examples.WPF
/p>

Answer 2

我想请教您用于构建应用程序的建议、意见和良好做法。

始终从业务层抽象出数据访问实现。使用旧的C# interface's 指定合同；然后你可以有多个实现——你做出的任何糟糕的技术选择都会被最小化，因为你可以使用其他东西来实现。其他人如果真的愿意也可以开发自己的实现（该解决方案更具可扩展性），并且更容易测试。

我喜欢它们的分层效果——正如 Zihotki 指出的那样，你可以松散几张；只要您有单独的 Ui 业务逻辑层和抽象的数据访问，我会很高兴。

您会添加或删除任何列出的图层吗？你更喜欢什么技术？

我不能说具体细节，但这确实取决于您想要做什么以及谁将在系统上工作，例如：这将是开源的吗？如果您的客户群包括开发人员，那么您需要评估他们可能想要什么，并将其与您的其他需求相平衡。我觉得你的名单很好。我不会使用 NHibernate，因为我没有任何使用经验 - 但这更多是基于个人历史而不是证据。

如果您正在考虑 ORM 工具（如 NHibernate），我建议您考虑 LightSpeed，我的朋友（我尊重他们）对它评价很高。

那么第一个问题就是要不要使用存储过程和触发器？

我强烈主张使用 SP，尤其是在 Web 环境中，因为（正确地）它们提供了更好的保护级别来对抗 SQL 注入攻击。

此外，仅仅因为您使用 SP 并不意味着您在其中包含业务逻辑。

触发器 - 它们在做什么？我希望没有任何与“业务逻辑”相关的东西:)

构建业务模型的业务对象。我会把所有的业务规则和验证放在这里。但是需要这一层吗？或者你会把所有的业务都放在第 3 层吗？

正如您可能已经知道的那样，我坚信将所有业务逻辑都放入业务层，这样更容易重用，并且一致性的优势应该是显而易见的 :)

Answer 3

我个人倾向于对我的所有应用程序（无论是 ASP.NET/PHP/etc）进行类似这样的设置：

[database (mssql, mysql, etc)]
[dal/orm (nhibernate, subsonic, phpactiverecord, etc)]
[controllers (business logic goes here)]
[models (often direct mirrors of the DAL, but not always, depending on controller logic; if you have a simple enough data structure, you can possibly eliminate this)]
[rest (simple web interface to the controller methods)]
[user interface (extjs/jquery/etc)]

在此设置中，DAL 层仅负责简化数据库查询，控制器负责根据最终用户实际使用数据的方式加载模型，以及UI 完全由 AJAX 驱动。

我有模型 和 数据对象的原因是它们并不总是一对一的映射。它们通常非常接近，但我可能会选择以一种方式将某些内容存储在数据库中，但将其呈现给用户另一种方式。这样你也可以在不破坏用户界面的情况下重新设计数据层:)。