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

Question

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

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

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

遗憾的是 E.F. 4 不支持空间数据类型或 SqlDependecy 缓存失效。所以对于我的一些数据访问，我决定使用 ADO .net 2 SqlCommands / 存储过程（我也认为在 SQL Server 内部预编译 SQL Spatial 函数是值得的）。

因此，根据我目前的理解，这是我的想法：

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 部分似乎有点不确定。不知道如何解决这个问题

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

祝你好运。我想知道结果如何。