.net 4 架构：MVC、WCF 数据服务、存储库模式、实体框架结合在一起？

Question

我有幸从头开始使用所有最新、最棒的 .net 4 位和 .net 4 位版本。鲍勃。我的应用程序必须支持不同的客户端，包括 MVC 网站、iphone 应用程序、andriod 应用程序和应用程序。其他网站

我的应用程序处理相当多的空间数据，并且需要依赖缓存，因为它公开地理 RSS 提要，以允许在 Bing Maps Ajax 7 上将区域渲染为多边形。

我知道我想使用上述所有技术，但是我还不能 100% 确定它们是如何组合在一起的。

遗憾的是 EF 4 不支持空间数据类型或 SqlDependecy 缓存失效。因此，对于我的一些数据访问，我决定依靠 ADO .net 2 SqlCommands/存储过程（我还认为预编译 SQL Spatial 函数并在 SQL Server 内部发生是值得的）。

因此，根据我目前的理解，我的想法如下：

1）我将有一个 .edmx，它可以对没有空间属性的类型进行数据访问。然后，我将为那些与 .edmx 对话并返回 POCO 对象的类型提供存储库（使用 EF4 Poco 模板）。

2) 我将拥有带有空间位类型的手写 ADO .net 2 代码的存储库。

3）我将拥有封装存储库的服务层类（手写）（不知道它们是如何实现的或它们正在谈论什么）。在这里我将实现安全和业务逻辑。

4) 我将在一个单独的应用程序中部署一个 WCF 数据服务 (.net 4)，该应用程序将服务层公开为 OData 供不同客户端使用。

5) 我的 MVC 将通过控制器代码与我的 WCF 数据服务层通信。

6) 其他客户端将与 WCF 数据服务层对话并按照他们希望的方式处理 OData。

这有道理吗？使用 OData 来调用业务操作而不仅仅是 CRUD？ Odata 的安全性和身份方面是否存在主要障碍和挑战者？

另外，它是否会太繁重，我是否应该寻找某种类型的混合动力以获得更好的性能和性能？更少的代码，比如直接与我的网络应用程序中的 (3) 对话并打破层蛋糕？

Answer 1

这里有严厉的爱。

如果您不了解想要使用的技术，请不要对您的应用程序进行 BFUD（大型预先设计）。你这样做弊大于利。使用最流行的模式！=成功。

从小处开始，长出一些小碎片，然后从那里开始成长。

Answer 2

同意下面的观点，听起来系统架构中有相当多的未知数 - 尽可能保持简单 - 拥有 2 个独立的 DAL（ODATA 和您的自定义 DAL）是代码可维护性地狱的秘诀。 -您可能想跳过 odata 部分。

如果您的客户端需要与 ODATA 服务 REST 数据同时访问空间数据类型，那么您的第 2 部分和第 3 部分、第 6 部分似乎有点不确定。不知道如何解决这个问题，

我会说 ODATA 可以很容易地被 .NET 客户端应用程序访问，并且支持通过 Javascript、Java 进行客户端访问（请参阅RESTLET） - 从我有限的 .NET 经验来看，这非常棒服务和 .NET 客户端 - 尚未在非 .NET 客户端上使用它，

祝你好运..我想知道这一切结果如何。