我们新申请的拟议架构如下所示
表示层 这将是在移动设备上运行的ASP.NET MVC应用程序
服务层 这将是一个WCF服务。 Presentation层使用自定义DTO与服务进行通信。
业务逻辑层 这是一个普通的c＃类库，其中写入了所有与businnes相关的逻辑。该层将Business对象公开给服务层。服务层使用实体转换器将Business对象转换为DTO
数据库访问层 我们正在为此计划EF4.1。我们希望有存储过程支持。因此，计划是使用Model First方法
这是我们的架构，我有以下问题
答案 0 :(得分：1)
而不是拥有Business Objects 和实体分开，我们可以 结合这两个。这是好事 方法??
存储过程支持没有理由使用Model First - 我会倾向于代码优先，因为它可以让你从工具中获得更多。
由于客户端是基于Web的，是吗？ 好的，使用自我追踪实体??
如果它是基于网络的..为什么你会打扰自我跟踪实体..？您可以一次性提交更改。正如它在the MS page上所说的那样：
仅在使用自我跟踪实体时才使用 对象上下文不可用于 层对象的更改位置 图表制作完成。如果是对象上下文 可用，使用EntityObject派生 类型或“普通的”CLR对象 （POCO）类型或POCO代理类型。对于 更多信息，请参阅使用 对象。
如前所述 - 我倾向于POCO，因为从长远来看，它会更容易合作。
可以给我发一些关于如何的链接 优化绩效
优化性能是很好的，取决于你正在做什么或你正在解决的问题..但一般来说，你会希望最大限度地减少使用电线 - 从网络服务器到网络服务器的电线数据库或从移动客户端到Web服务器的连线。
另请注意，关于此主题还有一些问题，例如：
Performance reprogramming website in MVC3 with Entity Framework enter link description here