哪种方法更好:1)使用第三方ORM系统或2) 手动编写DAL和BLL代码以使用数据库？

1)在我们的一个项目中,我们决定使用DevExpress XPO ORM系统,我们遇到了许多浪费了很多时间的轻微问题.Amd仍然不时遇到来自这个ORM的问题和例外,我们对这个"黑匣子"没有充分的理解和控制.

2)在另一个项目中,我们决定从头开始编写DAL和BLL.虽然这意味着编写无聊代码很多次,但这种方法被证明更加通用和灵活:我们可以完全控制数据在数据库中保存的方式,从中获取数据等等.所有的错误都可以以直接和简单的方式固定.

哪种方法一般更好？也许问题只是我们使用的ORM(DevExpress XPO),也许其他ORM更好(比如NHibernate)？

是否值得使用ADO Entiry Framework？

我发现DotNetNuke CMS使用自己的DAL和BLL代码.其他项目怎么样？

我想获得有关您个人经历的信息:您在项目中使用哪种方法,哪种更好？

谢谢.

我们将在.Net重建我们的一个站点.我已经阅读了很多文章,并且非常喜欢将我们的项目分成数据访问层(DAL),业务逻辑层(BLL)和表示层(我们来自经典ASP)的想法,这对我们来说是一个巨大的进步).我也非常喜欢Linq to SQL.

由于Linq to SQL旨在快速开发,Linq to SQL是否真的可以拥有DAL,BLL和表示层？使用Linq to SQL,DAL会返回可能在BLL中修改的实体或linq代码吗？DAL和BLL与Linq to SQL之间的关系似乎是一个模糊的话题,没有达成共识 - 因为这对我们来说是一个巨大的跳跃,我绝对想要在进入任何事情之前制定一个好的游戏计划.

类型数据集看起来更适合这个,但如果我能得到与Linq类似的东西我会去那条路.

我想远离nHibernate和其他第三方库.

民间，

我有一个按名称空间划分的相当n层的ASP.NET项目，但我需要分为三个项目：数据层，中间层和前端。

我这样做是因为...

答：这似乎是正确的做法，并且

B）我在运行ASP.NET托管程序集的单元测试时遇到各种问题。

无论如何，我的问题是，您在哪里保存配置信息？

例如，现在，当实例化新的数据上下文时，我的中间层类（使用Linq到SQL）会自动从web.config中提取其连接字符串信息。

如果我的数据层在另一个项目中，可以/应该使用web.config作为配置信息吗？

如果是这样，单元测试（通常在单独的组件中）将如何提供soch配置信息？

感谢您的时间！

我希望我的数据访问层可以非常模块化地构建.
因此,我有数据检索方法,有时直接从业务层调用,有时由其他数据检索方法调用以创建对象依赖项.

在DAL中处理数据库连接的最佳方法是什么？

a)在每个方法中创建一个新连接,然后再处理它.
好:易于编写和使用.
坏:许多连接正在打开和关闭.(性能？)

b)将连接作为(可选)参数传递.
好:我可以为多个命令重用开放连接.
不好:我必须跟踪连接的所有权(谁必须关闭它？)并且不能使用非常简洁的"使用"语句.

c)还有别的吗？(单身连接可能？)

这是我第一次写一个真正的DAL,所以我真的可以从经验丰富的人那里得到一些帮助.

编辑:因为它似乎很重要,它是一个ASP.Net网站项目.

好的,我们有一个包含以下项目的解决方案:

• 商业逻辑
• 实体
• 数据访问
• 公用事业
• 单元测试
• 用户界面

它是一个非常大的企业级应用程序.我的问题是,我们在哪里放置实体框架？一方面,EF看起来像数据访问技术,应该进入DataAccess项目.但另一方面,它会生成自己的实体,这些实体应放在我们已经很大的实体项目中.

哪个项目更适合实体框架？

是否有可能将实体与EF中的持久性逻辑分开？

我有多层应用程序架构,有4个部分:

• 网络服务器/客户端层
• 用于处理进程之间交互的中间数据层
• 监控层
• 客户层由n个实例组成

客户/服务器层:

客户端/服务器层处理与使用自定义第2层协议实现的另一台计算机的异步网络通信.由于通信中内置的设计约束,它需要保持独立并能够异步地轮询/推送数据到数据层.

中间层:

目前使用数据库实现中间层.一个表包含可以调用的所有可能标签(大约120,000).第二个表包含第一个表的中间缓存,其中仅包含正在使用的值,这需要不断更新,并在请求新的项集合时刷新.第三个表是发送集合更新的位置,仅在请求挂起时包含数据.

监控层:

监视器层是一个多线程单片应用程序.它根据连接的监视器数量生成n个客户端实例.它管理所有客户端实例之间的全局状态,因为它们中的一个或多个可以共享相似/相同的状态.它创建所需值的唯一列表,管理在客户端需要不同标签集时发送更新请求,并管理重复更新.

显然,这并不理想.如果一个实例出现故障,可以将其余部分关闭.我想要做的是删除中间层,将其替换为监视器层,并使所有内容都作为监视器进程的子进程生成,以便在出现问题时可以随意重新生成(例如,通信心跳停止,客户端崩溃)等).

数据库看起来太沉重,不够专业,无法处理IPC(进程间通信).该程序是在极端时间限制下编写的,因此利用数据库是"简单的解决方案",期望它将来会发生变化.我非常喜欢谷歌Chrome的多进程架构的强大功能,但我对它们如何将所有进程绑定在一起(管道,tcp,？)知之甚少.

所以:

1. 我是否可以期望在数据库中使用IPC作为中间层可以显着提高性能？

2. 什么形式的IPC在Windows系统上是理想的？

3. 是否有可用的交叉平台(读取Linux)替代解决方案,如果将开发转移到Mono,可以使用它？

4. 我在哪里可以找到有助于开始的资源/示例？

注意:我知道这个系统的体系结构似乎不必要地复杂,但它作为更大系统的前端存在.此应用程序也是关键任务,因此稳定性胜过效率.

更新:

我在最初的问题中忘了提到.数据库数据/索引在引导时直接从ramdisk加载.已对数据库本身编制索引以获得最佳性能.需要频繁写入的表或值不会编入索引,但其余数据都是索引.

我正在寻找一种替代方法来衡量,因为数据库的优化已经达到极限,我认为还有很大的改进空间.

一旦我有时间绘制它,我就会上传一些架构图.

如果我的DAL使用dapper-dot-net,如何创建交易？

我的c#winform应用程序将在网络中使用,数据将保存到中央sql server.

我的用例需要使用事务.我可以使用dapper来做这个,还是需要使用像NHibernate这样的东西？

此外,如果我使用存储过程,是否存在此框架的任何风险或限制？由于任何可能的限制,我是否需要改变我的方法？

我正在使用Microsoft Visual Studio DAL,其中我正在执行获取/更新数据的传统方法,以通过从ItemDetails网站数据库的表中检索数据来显示所列网站项目的评论,以创建ItemDetails.aspx文件.我添加了一个DropDownList Control显示其类别中的所有项目.从下拉列表中选择类别时,它会显示该类别中的所有项目,并附加一个超链接"Show Details"以在网格视图中显示详细信息.我是新手,我不知道DAL为asp.net网站创建.需要简单的指导方针来为asp.net网站创建DAL.帮助将不胜感激.创建DAL而不是创建DAL的其他方法有哪些SQLadapter.

该开发仅限于Visual Studio 2010(客户端批准的软件).我们需要通过存储过程访问数据.我想避免让它过于复杂而且时间紧迫.我看到的大多数设计涉及EF和LINQ,不确定如何设计procs？

我想创建一个单独的代码库项目(使用Web UI):

Application.Domain
      -  Interact get/put stored procedures, entities

Application.Web
      - containing Web UI (JQuery, AJAX), WCF Service

谁能给我一些关于如何处理Application.Domain的示例代码？

例子,我读过:

• http://www.developer.com/net/dependency-injection-best-practices-in-an-n-tier-modular-application.html

  http://www.kenneth-truyers.net/2013/05/12/the-n-layer-myth-and-basic-dependency-injection/

DAL\AppDAL.cs:

public static IEnumerable<TasCriteria> GetTasCriterias()
    {
        using (var conn = new SqlConnection(_connectionString))
        {
            var com = new SqlCommand();
            com.Connection = conn;
            com.CommandType = CommandType.StoredProcedure;

            com.CommandText = "IVOOARINVENTORY_GET_TASCRITERIA";
            var adapt = new SqlDataAdapter();
            adapt.SelectCommand = com;
            var dataset = new DataSet();
            adapt.Fill(dataset);

            var types = (from c in dataset.Tables[0].AsEnumerable()
                         select new TasCriteria()
                         {
                              TasCriteriaId = Convert.ToInt32(c["TasCriteriaId"]), …

我的项目分层如下：

DAL (Entity)- > BLL (DTO)- > ApplicationComponent (ViewModel)。

将要ApplicationComponent访问的application（）的多个组件BLL。组件包括Windows服务，Web服务，Web API和MVC控制器。

我改造NHibernate Entity的对象DTO对象，而从通过他们DAL来BLL。在将此状态传递给时ApplicationComponent，BLL再次将其转换为ViewModel。

这可以帮助我区分关注点以及如何在每一层中处理数据。我不赞成NHibernate Entity出于以下原因返回对象：-

• 数据暴露给UI我想要隐藏的（或仅在需要时暴露），例如密码，用户类型，权限等。
• 在引用/联接上，NHibernate在访问属性时执行附加查询，这将使延迟加载的使用无效。
• 暴露给（of Entity）用户的不必要数据会造成错误的混淆和漏洞。
• 持久性实现泄漏到BLL/中UI。Entity不适用于UI。它不能UI在所有情况下都可用。
• 我们在属性上使用属性DTO进行用户输入验证，看起来有点奇怪Entity。

我使用这种方法面临以下问题：-

• 最大和明显的问题是具有相似成员和功能的冗余对象。
• 我必须在每一层中编写映射器方法以转换对象。可以通过使用AutoMapper或类似方法将其最小化；但是它不能完全解决问题。

问题：-

1. 是否过度分离，应该避免（至少将其最小化）？
2. 如果这种方法是正确的，那么我看不到任何简单的方法可以完全绕过我上面提到的两个问题。请提出建议。
3. 如果此方法不正确，请提出更正建议。

参考文献：

1. Link1建议将Entity对象转移到视图，在我看来这不是一个好主意。
2. Link2建议Entity …