从开发人员的角度来看 Sitecore
我刚刚开始研究 Sitecore，我想知道是否有人可以帮助我从开发人员的角度阐明它到底是什么/如何。
我已经浏览了他们的大量文档以及他们的 SDN - 在我看来，到目前为止，他们中的大多数只是通过他们的界面（即通过他们的“Sitecore Desktop”）拖放点击这里和那里，并进行了非常小的实际编程。
这是真的吗？或者他们的实际 C# / ASP.Net 编程是在幕后实现业务逻辑等？
我浏览了他们的基本教程（为产品创建基本网站），就像我上面提到的那样，这一切主要是通过他们的界面完成的，无需任何实际编程 - 与使用 ASP.Net MVC3 音乐商店教程相反，您可以在其中看到一些C# 编程。
谢谢！
I just started to look into Sitecore and I was wondering if anyone can help me enlighten what / how it is exactly from a developer perspective.
I've gone through bunch of their documentation and also their SDN - seems to me so far most of them are just drag/drop click here and there through their interface (ie. through their "Sitecore Desktop") with very minor actual programming.
Is this true? or are their actual C# / ASP.Net programming behind the scene to implement business logic and such?
I went through their basic tutorial (creating basic site for Product), and like I mentioned above, it's all mostly done through their interface without any real programming - as opposed to working with the ASP.Net MVC3 Music Store tutorial where you can see some C# programming.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一般来说，Sitecore 开发人员应该对 Sitecore 有最深入的了解。开发人员需要了解 CMS 用户的视角（即内容编辑者的 POV），他们需要了解内容树中内容的架构，并且他们需要了解他们构建的代码。开发人员应该对 Sitecore 解决方案有最深入的了解，因为您需要了解架构才能知道如何编码。了解架构意味着您知道内容编辑器将如何与内容交互。
架构
Sitecore 是一个增强的数据库。这样想吧。您可以按照自己的意愿构建网站。但是，一旦您开始学习 Sitecore 架构的原则和最佳实践，您就会注意到一种模式。内容树中的所有内容都是一个项目。每个项目的模型（在 Sitecore 术语中称为模板）由架构师（通常是开发人员）定义。事实上，即使有一个单独的人担任架构师角色，他们也可能拥有开发人员知识，因为架构定义了事物的开发方式。事实上，架构是最重要的事情之一。
代码
代码分为多种类型，但最简单的形式有两个主要内容：布局和子布局。
将布局视为普通 ASP.NET 应用程序使用 MasterPage 的用途。在 Sitecore 中，布局实际上是一个 ASPX WebForm，但它充当母版页。您的网站上可能有的一些布局示例包括：一栏布局、两栏布局、打印布局。这些将分别转换为具有一个主要内容区域的页眉和页脚、具有主栏和侧栏的页眉和页脚以及可能具有徽标和仅主要内容的打印优化布局。
子布局是构成页面的所有小组件。示例包括：主导航、侧栏中的促销框、最近 5 条新闻的列表、促销的 CTA、侧边栏幻灯片等。这些组件可以是模块化的，并可以由内容编辑器移动，或者它们可以固定在布局的位置内，例如，促销框可以始终出现在两列布局的侧边栏中，作为代码中定义的业务规则。
要回答您关于是否有实际编码的问题，是的。您可以使用 Sitecore 的 ASP.NET 控件和 Sitecore 的 C# API 编写代码，以访问填充到每个项目的模板中的数据。因此，如果您的页面项目具有标题标签的页面标题，您的代码将使用 Sitecore API 从模板访问“标题标签”字段（请记住，Sitecore 中的模板是一个数据模型）在 Sitecore 中。
Sitecore 编码
我想说有两种编码方法。我相信您已经找到了其中之一，它正在使用 Sitecore 界面中的内部工具。 Sitecore 有一个名为“开发人员中心”的部分，可让您创建布局和子布局。坦率地说，将此与始终在设计模式下使用 Visual Studio 进行比较。我从未使用过开发人员中心进行编码。相反，我在 Visual Studio 中进行编码，这是人们为 Sitecore 编码的最常用技术（至少我认为是）。现在，如果您想知道编码如何连接到 Sitecore 的数据……那么答案就在 Sitecore 中。树中有一个称为布局的部分。这里是布局和子布局的名称。每个布局和子布局项都有一个分别映射到 ASPX WebForm 或 ASCX 用户控件的路径。这就是 Sitecore 实际上使用您在 Visual Studio 中编写的文件系统上的代码的方式。然后通过Presentation > 来使用这些布局和子布局项。 Sitecore 中每个项目的详细信息选项卡。
初学者
使用 Sitecore 最困难的事情之一就是学习曲线。我已经使用 Sitecore 多年并且喜欢它。事实上，这就是我真正所做的一切。它是迄今为止我最喜欢的 CMS，因为它完全可定制并且对开发人员非常友好。 Sitecore 建议新开发人员参加开发人员培训课程，这样他们就可以在实际培训课程中基本上解释我上面解释的内容。在本次培训中，您将学习架构，以及代码如何与其连接。培训涉及内容树中的实践架构工作和实践编码。为新开发人员推荐的培训课程是：
A Sitecore developer should have the most intense and deepest understanding of Sitecore in general. Developers need to understand the CMS user's perspective (i.e. content editor's POV), they need to understand the architecture of content within the content tree, and they need to know the code, which they build. A developer should have the most intimate knowledge of a Sitecore solution because you need to know the architecture to know how to code. And to know the architecture means you know how content editors will interact with the content.
Architecture
Sitecore is a souped up database. Think of it like that. You can architecture a site how you want. But once you start to learn the principles of Sitecore architecture and best practices you'll notice a pattern. Everything in the content tree is an item. The model for each item (called a template in Sitecore terms) is defined by an architect (which is often often a developer). In fact, even if there's a separate person for the architect role, they likely have developer knowledge as architecture defines the way things are developed. In fact, the architecture is one of the most important things.
Code
Code is broken down into various types, but in its simplest form there are two main things: layouts and sublayouts.
Think of a layout as what a normal a ASP.NET application uses a MasterPage for. In Sitecore, a layout is actually a ASPX WebForm, but it acts as a master page. Some examples of layouts you could have on your site are: One Column Layout, Two Column Layout, Print Layout. These would respectively translate to a header and footer with one main content area, a header and footer with a main column and side bar, and a print-optimized layout with maybe a logo and just main content.
Sublayouts are all of the little components that make up a page. Examples include: main navigation, a promo box in your side bar, a list of 5 recent news pieces, a CTA for a promotion, a sidebar slide show, etc. These components could be modular and moved around by content editors, or they can be fixed within the location of layouts, e.g. a promo box could always appear in the sidebar of the Two Column layout as a business rule defined in the code.
To answer your question about is there actual coding, yes. You write code using ASP.NET controls for Sitecore and Sitecore's C# API to access data that is populated into the templates on each item. So, if you had an item for a page that had a page title for the title tag, your code would use the Sitecore API to access the field "Title Tag" from the template (remember a template in Sitecore speak is a data model) in Sitecore.
Coding For Sitecore
I'd say there are two approaches to coding. I believe you identified one of them, which is using the internal tools within Sitecore's interface. Sitecore has a section called Developer Center that lets you create layouts and sublayouts. Frankly, compare this to using Visual Studio in Design Mode all of the time. I have never once used the Developer Center to do my coding. Instead, I code in Visual Studio which is the most common technique for people to code for Sitecore (at least I think it is). Now if you're wondering, how does the coding connect to Sitecore's data... well the answer is within Sitecore. There's a section of the tree called Layouts. In here are the names of your layouts and sublayouts. Each layout and sublayout item has a path that maps to either a ASPX WebForm or ASCX User Control, respectively. This is how the code on the file system that you write in Visual Studio actually gets used by Sitecore. These layout and sublayout items are then used via the Presentation > Details tabs for each item in Sitecore.
Beginners
One of the hardest things with Sitecore is the learning curve. I've been using Sitecore for years now and love it. In fact, its all I really do. It's by far my favorite CMS as its completely customizable and very developer-friendly. Sitecore recommends that new developers take the developer training classes so they can basically explain what I explained above in an actual training curriculum. In this training you will learn the architecture, and then how the code connects to it. Training involves hand-on architecture work within the content tree and hands-on coding. The recommend training courses for new developers are:
Sitecore 是一个 ASP.NET 应用程序。这意味着您可以编写任何您喜欢的代码。我们的团队自己在 Visual Studio 中创建所有子布局（ASCX 文件）和布局（ASPX 文件），而不是 Sitecore 内置的编辑器。
我见过的一些 Sitecore 安装几乎不依赖 CMS 来进行渲染。相反，值是通过代码隐藏来提取的，就好像 Sitecore 只是一个数据库一样。在某些情况下这可以很好地工作。
最令人印象深刻的 Sitecore 实例使用了开发人员可以访问的所有可用工具。按照设计的方式使用 Sitecore 工具，可以为（通常是非技术性的）内容编辑者提供一些令人印象深刻的编辑选项。
例如：使用 Sitecore Fieldrenderer 而不仅仅是占位符或标签不仅会自动适当地呈现内容（无论是图像还是富文本），而且还允许内容编辑器直接在网页上编辑内容 而不是所有 CMS 系统都拥有的唯一后端。
工作流程是另一个杀手级功能，对于规模合适、能够负担得起 Sitecore 费用的客户而言。它允许您为树中的项目构建批准流程。这样，法律、营销和图形团队就可以在新页面上线之前全部签字。然后，当所有批准完成后，网站将自动发布。
总结一下：Sitecore 是一个 .NET 应用程序，您可以编写任何您想要的代码。这意味着您应该关注 CMS 功能，并确保从内容编辑者的角度和财务的角度来看它非常适合您。
Sitecore is an ASP.NET application. That means that you can write any code you like. Our team creates all of the Sublayouts (ASCX files) and Layouts (ASPX files) ourselves in Visual Studio, not the editors built in to Sitecore.
Some installations of Sitecore that I have seen barely rely on the CMS to do the rendering. Instead values are pulled via the codebehind as if Sitecore was just a database. That can work fine in some situations.
The most impressive Sitecore instances use all of the available tools that the developer has access to. Using the Sitecore tools the way they were designed to be used allows some pretty impressive editing options for the (often non-technical) content editors.
For example: Using a Sitecore Fieldrenderer instead of just a placeholder or label will not only automatically render content appropriately (whether they are images or rich text), but it will allow the content editor to edit the content right on the web page as opposed to the only on back end that all CMS systems have.
Workflow is another killer feature for a customer that is the right size to afford Sitecore. It lets you build an approval process for items in the tree. That way legal, marketing and the graphics team call all sign off on a new page before it goes live. Then when all of the approvals are finalized, the site publishes automatically.
To sum up: Sitecore is a .NET application, you can code whatever you want. That means you should focus on the CMS features and make sure it is a good fit for you from a content editor perspective and a financial perspective.
Sitecore 在大多数情况下只是拖放正如您在内容创作方面所描述的那样，但要真正将此内容转换为网页，您需要实现布局、子布局等。
布局是通用的 ASP.NET 页面 (aspx)，子布局只是 Web 控件 (ascx)，如果您愿意，还可以使用 XSLT 生成 HTML，但它仅对基础有用（Sitecore 目前仅支持 XSLT 1）。这些 ASP.NET 控件与带有代码隐藏等功能的标准 Web 表单控件不太相同。不同之处在于 Sitecore 是您的数据源，它为您提供了一个 API 来访问所有相关应用程序。
但 Sitecore API 还不止于此，它允许您以编程方式访问框架的几乎任何组件。这些 API 文档齐全且非常易于理解，可用于更复杂的场景。
如果您不太喜欢 Web 表单，最新版本的 Sitecore (6.4) 还允许您使用 MVC 框架来创建布局/子布局。
Sitecore is in most cases just drag & drop as you've described in terms of content authoring but to actually turn this content into a webpage you need to implement layouts, sublayouts and so on.
Layouts are generic ASP.NET pages (aspx), sublayouts are just web controls (ascx) and if you prefer you can also use XSLT to generate HTML but it's useful only for basics (Sitecore only supports XSLT 1 at this moment). These ASP.NET controls are more less the same as standard web forms controls with code behind and so on. The difference is that Sitecore is your datasource and it gives you an APIs to access all relevant applications.
But Sitecore APIs also goes beyond that and allows you programatic access to virtually any component of the framework. The APIs are well docummented and quite easy to understand and they can be used for more complex scenarios.
Latest version of Sitecore (6.4) allows you to also use MVC framework for layouts/sublayouts creation if you don't like web forms that much.
从编码的角度来看，布局和子布局是进行任何自定义的好方法，但这里没有提到第三种方法。我们称之为站点核心扩展。我经常发现，为了满足客户要求，为工作流操作或模板命令创建自定义程序集是唯一的方法。
例如，进入工作流程状态时的标准电子邮件通知仅允许您将服务器、收件人、描述等应用到操作项字段。就我们而言，这些价值观不断变化，因此我们需要更加动态。应用于操作的自定义程序集使我们能够灵活地执行标准操作无法完成的许多操作。另一个例子是，我们需要让项目中的树列表滚动到并突出显示当前项目。执行此操作的方法是使用我们的自定义程序集覆盖核心树列表操作。
请记住，向布局添加大量代码（可能是大量页面的母版页）会增加运行时开销。
Layouts and sublayouts are a great way todo any customizations from a coding standpoint but there is a third way that is not mentioned here. We call it sitecore extensions. I often find that to meet customer requirements, creating custom assembly's for workflow actions or template commands is the only way.
For example, a standard email notification upon entry into a workflow state only allows for you to apply server, recipient, description etc.. to action item field. In our case these values constantly change so we need to be more dynamic. A custom assembly applied to the action allows us the flexibility to do a number of things that the standard action will not. Another example was that we needed to have a treelist in an item scroll to and highlight the current item. The way todo this was to override the core treelist action with our custom assembly.
Keep in mind that adding alot of code to the layout (which could be a master page for a ton of pages) ramps up the runtime overhead.
从用户体验的角度来看，Sitecore 不切实际、功能强大且过于复杂，无法为具有典型内容贡献者和编辑者的团队有效实施。没有考虑简化内容创建或简单的页面模板维护。我绝不会向没有以下能力的团队推荐 Sitecore：
该系统是为开发人员构建的，而用户是一个非常遥远的事后想法。根据我的经验，它提供了很多好处——成为日常内容作者可用的系统并不是其中之一。该系统是如此模块化和过度管理，它迫使各个级别的用户做出决策，而这些决策只会使原本简单的操作变得复杂。内容发布非常模块化，这对开发者来说是一个很大的好处；对于日常用户来说这是一场灾难。
如果您是开发人员，Sitecore 是一个很棒的构建环境。它功能强大且灵活。
如果您是用户，Sitecore 的任务繁重，并且提供了我所遇到的 CMS 中最陡峭的学习曲线。 UAT 一直是一场噩梦。
From a UX perspective, Sitecore is impractical, overpowered and too complex to be effectively implemented for teams with typical content contributors and editors. No thought has been put into streamlining content creation or simple page template maintenance. I would never recommend Sitecore to a team without:
The system is built for developers, with users as a very distant after-thought. In my experience, it offers a huge number of benefits — being a usable system for every-day content authors is not one of those benefits. The system is so modular and over-managed, it forces users on every level to make decisions that only complicate otherwise simple operations. Content publishing is extremely modular, and a big benefit for developers; it is a catastrophe for everyday users.
If you're a developer, Sitecore is a wonderful building environment. It's powerful and flexible.
If you're a user, Sitecore is task-heavy and offers the steepest learning curve I've ever encountered with a CMS. UAT has been a nightmare.