Принудительное оформление атрибутов классов / методов
Следуя моему недавнему вопросу о Большие сложные объекты как результат веб-службы. Я думал о том, как обеспечить сериализацию всех будущих дочерних классов в XML.
Теперь, очевидно, я мог бы реализовать интерфейс IXmlSerializable, а затем подключить к нему читателя / писателя, но я бы хотел избежать этого, поскольку тогда это означает, что мне нужно создавать экземпляр ридера / писателя всякий раз, когда я хочу это сделать, и в 99,99% случаев Я собираюсь работать с нить, поэтому я могу просто написать свой собственный.
Однако для сериализации в XML я просто украшаю класс и его члены атрибутами Xml ??? (XmlRoot, XmlElement и т. д.), А затем передаю его в XmlSerializer и StringWriter, чтобы получить строку. Что все хорошо. Я намерен поместить метод возврата строки в универсальный служебный метод, поэтому мне не нужно беспокоиться о типе и т. д.
Меня беспокоит следующее: если я не украшаю класс (-ы) необходимыми атрибутами, ошибка не выдается до времени выполнения.
Есть ли способ принудительного оформления атрибутов? Можно ли это сделать с помощью FxCop? (FxCop еще не использовал)
ОБНОВИТЬ:
Извините за задержку с этим, ребята, много работы!
Определенно нравится идея использовать отражение, чтобы сделать это в тестовом примере, а не прибегать к FxCop (например, чтобы все было вместе) .. Ответ Фредрика Калсета был фантастическим, спасибо за включение кода, поскольку это, вероятно, потребовало бы мне немного покопаться, чтобы понять как это сделать самому!
+1 другим ребятам за похожие предложения :)
Ответы 5
Я бы написал тест модуля / интеграции, который проверяет, что любой класс, соответствующий некоторым заданным критериям (то есть подкласс X), оформлен соответствующим образом. Если вы настроили свою сборку для запуска с тестами, у вас может произойти сбой сборки, когда этот тест завершится ошибкой.
ОБНОВЛЕНИЕ: Вы сказали: «Похоже, мне просто нужно будет засучить рукава и убедиться, что модульные тесты поддерживаются коллективно» - вам не нужно. Просто напишите общий тестовый класс, который использует отражение, чтобы найти все классы, которые необходимо утверждать. Что-то вроде этого:
[TestClass]
public class When_type_inherits_MyObject
{
private readonly List<Type> _types = new List<Type>();
public When_type_inherits_MyObject()
{
// lets find all types that inherit from MyObject, directly or indirectly
foreach(Type type in typeof(MyObject).Assembly.GetTypes())
{
if (type.IsClass && typeof(MyObject).IsAssignableFrom(type))
{
_types.Add(type);
}
}
}
[TestMethod]
public void Properties_have_XmlElement_attribute
{
foreach(Type type in _types)
{
foreach(PropertyInfo property in type.GetProperties())
{
object[] attribs = property.GetCustomAttributes(typeof(XmlElementAttribute), false);
Assert.IsTrue(attribs.Count > 0, "Missing XmlElementAttribute on property " + property.Name + " in type " + type.FullName);
}
}
}
}
Вы можете написать модульные тесты для проверки такого рода вещей - в основном они используют отражение.
Учитывая тот факт, что это возможно, я предполагаю, что также можно было бы написать правило FxCop, но я никогда не делал ничего подобного.
Вы можете написать правило FxCop или даже проверить атрибуты, вызвав GetType () в конструкторе базового класса и проанализировав возвращаемый тип.
Хорошее правило FXCop (которое я считаю нужным прямо сейчас) - это проверка того, что все объекты, добавляемые в сеанс ASP.NET, имеют атрибут Serializable. Я пытаюсь перейти из состояния сеанса InProc в SQL Server. В первый раз, когда я запросил страницу, мой сайт взорвался, потому что несериализуемые объекты хранились в Session. Затем пришла задача перебрать весь исходный код в поисках каждого экземпляра, в котором объект установлен в сеансе ... FXCop был бы хорошим решением. Над чем поработать ...
Вы также можете использовать эту концепцию / постпроцессор для обеспечения взаимосвязей между атрибутами и использовать аналогичный вход в систему для обеспечения взаимосвязей между классами и атрибутами во время компиляции:
http://www.st.informatik.tu-darmstadt.de/database/publications/data/cepa-mezini-gpce04.pdf?id=92