问题标签 [oxite]

微软发布了Oxite的源代码，他们的博客引擎旨在帮助 .NET 开发人员学习 ASP.NET MVC。他们还发布了使用 Oxite 构建的Mix站点的源代码。

微软表示，开发人员可以使用 Oxite 构建应用程序，因为它具有许多内置功能，如引用、pingback 和 RSS 支持。

你打算使用 Oxite 来学习 ASP.NET MVC 吗？你认为你可以用它做任何有用的事情吗？

我想建立一个基于 Asp.Net Mvc 的 CMS 站点，我想选择我的起点。

我已经看到，如果在生产项目中采用它似乎还为时过早，那么人们对新的 Microsoft Oxite 项目也很感兴趣。
我还查看了 S#arp 架构，但它不能与 Oxite 进行正确比较，因为它只是一般 Asp.Net Mvc 站点的起点。

对我来说，S#arp 架构比 Oxite 有一些优势，因为它的复杂性要低得多，并且它使用 Nhibernate 作为数据访问层。
Oxite 代码使用 Linq2Sql 作为 DAL，并且在解决方案中已经有一个项目需要 VS2008 的 DB 版本。
在我看来，Oxite 似乎更面向博客而不是面向 CMS，但我没有深入查看代码。

以下是一些将我指向 S#arp Ar 的选择。开始。

• 简单干净的架构
• 冬眠木豆
• 社区支持

氧化物：

• 微软项目
• 潜在的巨大社区
• 早期阶段，但代码质量非常好
• 允许轻松切换 DAL 的提供程序模型

如果有人看过这两个项目的代码，请提出您的意见。

谢谢

我将通过承认我对 MVC 非常陌生来开始这个问题。设计模式在较高层次上对我来说很有意义，但现在我正在探索 ASP.NET MVC，一些架构部分正在挑战我的先入为主的观念。学习是好事。

我最近一直在使用Oxite作为一种学习工具，由创建 ASP.NET MVC的公司的人员编写，因此，它是一个表面上的 ASP.NET MVC 参考应用程序。

但今天我看到Rob Conery写的一篇关于 Oxite 的博文，上面写着：

Oxite 团队决定做的一件事是将控制器和视图分离到另一个项目中，因为我只能假设业务逻辑与视图逻辑的分离。这可能会导致一些混乱，因为控制器旨在处理应用程序流 - 不一定是业务逻辑。

这让我陷入了困境。这种分离是 MVC 的一个原则，因此是 Oxite 开发人员的错误，还是 Rob 的观点？如果业务逻辑属于模型，为什么 Oxite 团队将其放在控制器中？如果不在控制器中，我如何执行作为业务逻辑的操作？

除此之外，考虑到 Rob 的评论，我是否在使用 Oxite 作为学习基准时犯了错误？

我需要做一个带有博客和论坛的社区站点，并且正在寻找 3 个选项：Oxite、DNN 和社区服务器。前端将是 ASP.NET 和 Silverlight 的混合体。LiveID 集成将是一个加分项。有什么建议么？

谢谢。

阅读 Oxite 源代码，我发现验证器使用一些后缀（RequiredError、MaxLengthExceededError、InvalidError、FormatError）保存错误的属性名称

谁的后缀的目的是什么？他们是怎么用的？

我们正在研究将 Orchard CMS 用于一个项目。我知道 CMS 已经存在很长时间了，但我想知道是否有使用 Orchard CMS 或其前身 Oxite 的知名且成功的案例研究？

谢谢。

我刚刚下载了Oxite 博客引擎。下载的包中缺少一些 dll，即 Microsoft.Practices.ObjectBuilder2.dll 和其他带有 Microsoft.Practices 前缀的 dll。我在哪里可以找到这些程序集？