Какая разница между фрагментами кода С# и сборками TBB?

Я понимаю, что фрагменты кода С# и .NET Assemblies предлагают те же функции для модульной разработки шаблонов. Мы управляем фрагментами кода в CME и ассемблерном коде в Visual Studio, но используем одинаковый способ в Template Builder.

В терминах кода я могу создать блок построения шаблонов фрагмента кода С# (TBB), например:

var timeStamp = DateTime.Now.ToString("d MMM yyyy");
package.PushItem("timeStamp from fragment", package.CreateHtmlItem(timeStamp));

Я также могу создать сборку шаблонов сборки .NET с использованием того же кода, выполнив ITemplate, как показано ниже.

using System;
using Tridion.ContentManager.Templating;
using Tridion.ContentManager.Templating.Assembly;

namespace CreateAndBreakTemplates
{
  [TcmTemplateTitle("Add Date to Package")]
  public class AddDateToPackage : ITemplate
  {
    public void Transform(Engine engine, Package package)
    {
      var timeStamp = DateTime.Now.ToString("d MMM yyyy");
      package.PushItem("timeStamp from assembly", 
                       package.CreateHtmlItem(timeStamp));
    }
  }
}

docs объясняют, что "SDL Tridion вставляет фрагмент кода в свой предопределенный метод предопределенного класса". Похоже, этот класс реализует ITemplate и добавляет некоторые ссылки ниже (я что-то пропустил?).

В инструкции по установке сборки упоминаются, по крайней мере, эти DLL.

  • Tridion.Common.dll
  • Tridion.ContentManager.dll
  • Tridion.ContentManager.Templating.dll
  • Tridion.ContentManager.Publishing.dll

Любая другая разница между фрагментом и сборкой и как вы бы выбрали между ними?

Ответы

Ответ 1

Фрагмент С# скомпилирован в сборку Tridion при первом вызове шаблона и после его изменения. Чтобы скомпилировать фрагмент, Tridion обертывает его в какой-то "подземелье" (бонусные баллы для тех, кто знает, откуда этот термин):

  • Использует пространства имен Tridion.ContentManager, Tridion.ContentManager.CommunicationManagement, Tridion.ContentManager.ContentManagement и Tridion.ContentManager.Templating
  • Делает Package и Engine доступными в полях Package и Engine соответственно
  • Создает регистратор для фрагмента С#, доступного через поле под названием log
  • Добавляет ссылки на некоторые часто используемые сборки (но еще не добавляет using для своих пространств имен)

Изменить:, учитывая другие ответы, многие люди не знают о том, как выполнить определенные задачи в TBB-фрагментах С#, поэтому я опишу их ниже:

Импортировать дополнительные пространства имен

Чтобы импортировать/использовать дополнительные пространства имен в ваш фрагмент С#, вам необходимо использовать этот синтаксис:

  
<%@ Import Namespace="Tridion.ContentManager.ContentManagement.Fields" %>

Обратите внимание, что это будет импортировать пространства имен из сборок, на которые уже ссылается Tridion. Нет никакого механизма, чтобы вы могли явно добавлять ссылки на другие сборки; поэтому, если вам нужна сторонняя DLL, вам нужно будет добавить ее в GAC.

Определение пользовательских функций

Вы можете определить пользовательские поля и функции в своем фрагменте С# с помощью этого синтаксиса:

<%!

public static string GetDate()
{
    return new DateTime().ToString("u").Replace(" ", "T");
}

%>

Определение полей-членов и (вложенных) классов

Синтаксис для определения пользовательских функций также позволяет вам определять вложенные классы и/или поля членов:

<%!

public class MyLittleHelper
{
    public MyLittleHelper(string param1)
    {
    }
}

%>

Ответ 2

Фрэнк объяснил разницу между двумя подходами, но это все еще оставляет вопрос о том, как выбирать между этими двумя. Мой личный совет заключается в том, чтобы никогда не использовать фрагменты С# для чего угодно, только с одним исключением *. Как вы узнали, в них происходит какая-то темная магия, которую мне лично не нравится. Кроме того, вы так много не можете сделать в них, что .NET-программист очень любит, например, создавать классы.

Отвлекая мой личный вкус, я вижу только одну причину, по которой вы когда-либо прибегали к фрагментам С#: если у вас нет доступа к Visual Studio или другому инструменту, который создает библиотеки DLL. И это тоже не очень сильный аргумент: если вы хотите выполнить задание, вы должны получить правильные инструменты!

* Исключение составляют фрагменты С#, которые Tridion автоматически создает для каждой ITemplate в вашей сборке, конечно.

Ответ 3

Основные различия между С# -кодом Fragment и .net Сборка в моей точке зрения подразделяется на нижние ковши высокого уровня.

Пошаговая отладка

С сборками .net вы можете делать пошаговую отладку из visual studio, где в качестве фрагментов кода С# это невозможно.

Повторное использование или базовые классы

С сборками .net вы можете расширить ITemplate, чтобы создать что-то вроде BaseTemplate, и весь ваш шаблон мог бы расширить их, чтобы у вас был общий шаблон проектирования, где в С# нет понятия BaseTemplate, кроме интерфейса Trimion ITemplate.

С сборками .net вы можете добавить общие классы утилиты (часто TridionUtilities), и все ваши шаблоны относятся к тем же TridionUtilities для общей функциональности. Фрагмент кода С#, функции утилиты должны быть определены в одном TBB и не могут быть повторно использованы с другими TBB, если вы не создадите класс и не примените его к GAC.

Простейшие обновления и обслуживание

С сборками .net проще выполнять любые обновления, такие как устаревшие API/методы, просто ссылаясь на новую инфраструктуру dlls/.net..net упрощают определение потенциальных воздействий на планирование обновлений Tridion или обновлений .net. С# фрагменты кода намного сложнее найти устаревшие или любые последствия обновления.

Дружественный для разработчиков

Очевидно, сборки .net разрабатываются с использованием Visual Studio (разработчики любят это!) и фрагментов кода С# в текстовом редакторе (больно).

Когда я вернулся с Tridion 5.3, начал с фрагментов кода С# и быстро понял, какую ошибку я сделал для не собирающихся сборок .net.

Мой голос - это всегда сборки .net и фрагменты кода С#, даже если у меня нет выбора. лол..

Ответ 4

Я думаю, что различия действительно лучше всего объясняются ответом Фрэнка, как бы вы выбрали между ними. Обычно я говорю, поскольку вы используете Visual Studio в любом случае, всегда создавайте .NET Assembly TBB для своего кода. Они предлагают вам гораздо больше преимуществ, таких как включение сторонних сборок, позволяют правильно кодировать классы и методы намного проще и, вероятно, наиболее важно, позволяют правильно отлаживать (хотя эту последнюю сложно настроить в зависимости от того, где вы находитесь, среды клиента, брандмауэров и т.д.).

Есть только два исключения для использования фрагментов С#:

  • Ссылки на классы, реализующие ITemplate в сборке, позволяющие использовать их в качестве отдельных TBB
  • Если требуется управлять константами или другими жестко закодированными константами непосредственно из SDL Tridion

Номер 2, конечно, спорный, но вы никогда не можете обойтись без свойств конфигурации. Для большинства из них вы можете обращаться с помощью схемы параметров, но иногда это намного проще, чтобы напрямую писать их в фрагменте С# и они подталкивают их к пакету для использования других TBB.

В моих учебных занятиях я обычно ссылался на следующую историю о том, как единственный раз, когда я когда-либо выбирал использовать TBB Fragment TBB, показывая, сколько из его исключения должно использоваться:

Я работал у клиента за границей, и мое такси в аэропорт уходило через 10 минут, когда один из разработчиков, которых я тренировал, задал мне вопрос о том, как получить список предметов из папки в своем TBB. Я уже закрыл свою Visual Studio и Outlook и собирался закрыть свой ноутбук, но быстро просмотрел некоторые мои образцы кода, чтобы найти то, что ему нужно. Зная, что запуск Visual Studio или Outlook займет несколько минут, я быстро вставил код в фрагмент С#, чтобы он мог легко найти ссылку.

Ответ 5

Я бы никогда не использовал фрагменты С# по той причине, что это затрудняет управление вашим кодом, и вам необходимо вручную их развернуть. И если вы пишете свой код из Visual Studio, тогда вы должны создать сборку .NET Building Block.