我想问一个关于在.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。
答案 0 :(得分：3)
如果你想使用一些嵌入式sql数据库，你应该看看SQLite。它具有比SQL CE更多有用的功能，并且工作得更快，没有问题。或者甚至更多，我建议您使用一些文档或对象数据库（例如db4o）。 IMO，它将简化您的DAO和代码。
1，我更喜欢使用ORM，我很少使用存储过程和触发器，只在遗留应用程序中使用。处理c＃代码并将所有代码放在一个地方要容易得多。你对逻辑和业务规则是正确的。
2，我更喜欢使用NHibernate作为最成熟，最强大和可定制的框架。我还建议您查看NhProf（换句话说，L2S和EF存在相同的分析器）。
3＆amp; 4，只需将其移除，不必要的噪音和猴子工作。
2＆amp; 5，使用您的数据库模型作为BusinessModel（使用NHibernate非常容易）。查看this和this条款。
6＆amp; 7，对于web我选择MVC with asp.net mvc，for WPF-MVVM。根据我的经验，当您没有遗留代码等限制时，请不要使用WinForms和Asp.Net。使用Asp.Net Mvc和WPF进行开发更加简单有趣。并且有很多很酷且省时的框架 - MvcTurbine，MVC Contrib，SharpArchitecture用于asp.net mvc和Caliburn，WPF Toolkit，{ {3}}，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
答案 1 :(得分：3)
我想问一下您用于构建应用程序的建议，意见和良好实践。
始终从业务层中抽象出数据访问实现。使用好的旧C# interface指定合同;然后，您可以拥有多个实现 - 您所做的任何不良技术选择都会被最小化，因为您可以使用其他方法实现。其他人也可以开发自己的实现，如果他们真的想要（解决方案更具可扩展性），并且更容易测试。
我喜欢他们的分层 - 就像Zihotki指出的那样，你可以松开一对夫妻;只要你有独立的Ui业务逻辑层和抽象的数据访问，我就会很高兴。
您是否会添加或删除任何列出的图层？您更喜欢哪些技术？
我不能说具体细节但它确实取决于你想做什么以及谁将要在系统上工作，例如：这是开源的吗？如果您的客户群包括开发人员，那么您需要评估他们可能需要的内容，并与您的其他需求保持平衡。我觉得你的清单很好。我不会使用NHibernate，因为我没有任何经验 - 但这更多地基于个人历史而非证据。
如果您正在考虑使用ORM工具（如NHibernate），我建议您考虑LightSpeed，我的朋友（我尊敬的人）非常高兴地说。
所以第一个问题是是否使用存储过程和触发器？
我非常强烈主张使用SP，特别是在Web环境中，因为（正确完成）它们提供了更好的保护级别SQL注入攻击。
另外，仅仅因为你使用SP并不意味着你有业务逻辑。
触发器 - 他们在做什么？我希望没有“商业逻辑”相关：）
构建业务模型的业务对象。我在这里列出了所有业务规则和验证。但这层需要吗？或者您会将所有业务内容放入第3层吗？
正如您可能已经解决的那样，我坚信将所有业务逻辑放入业务层，它将更容易重用，并且一致性的优势应该是显而易见的：）
答案 2 :(得分：0)
对于我的所有应用程序（无论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层负责简化查询数据库，控制器负责根据最终用户实际使用数据的方式加载模型，以及用户界面完全由AJAX驱动。
我有模型和数据对象的原因是他们并不总是一对一地映射。它们通常非常接近，但我可能会选择以某种方式在数据库中存储某些内容，但会将其呈现给用户另一种方式。这样你也可以在不破坏用户界面的情况下重做数据层：）。