скажем, у меня есть
public delegate DataSet AutoCompleteDelegate(
string filter, long rowOffset);
могу ли я создать следующий класс для принудительного применения сигнатуры этого метода? (просто придуманная идея):
public class MiddleTier
{
[Follow(AutoCompleteDelegate)]
public DataSet Customer_AutoComplete(string filter, long rowOffset)
{
var c = Connect();
// some code here
}
[Follow(AutoCompleteDelegate)]
public DataSet Item_AutoComplete(string filter, long rowOffset)
{
var c = Connect();
// some code here
}
// this should give compilation error, doesn't follow method signature
[Follow(AutoCompleteDelegate)]
public DataSet BranchOffice_AutoComplete(string filter, string rowOffset)
{
var c = Connect();
// some code here
}
}
[EDIT]
Цель: я уже поместил атрибуты в методы моего посредника. У меня есть такие методы:
public abstract class MiddleTier : MarshalByRefObject
{
// Operation.Save is just an enum
[Task("Invoice", Operation.Save)]
public Invoice_Save(object pk, DataSet delta);
[Task("Receipt", Operation.Save)]
public Receipt_Save(object pk, DataSet delta);
// compiler cannot flag if someone deviates from team's standard
[Task("Receipt", Operation.Save)]
public Receipt_Save(object pk, object[] delta);
}
затем, во время выполнения, я буду перебирать все методы посредника и помещать их в коллекцию (здесь очень помогают атрибуты), а затем отображать их в функциях делегатов winform (облегченных интерфейсом, системой на основе плагинов) как загруженные
Я думаю, смогу ли я сделать атрибуты более самоописуемыми, чтобы компилятор мог улавливать несоответствия.
namespace Craft
{
// public delegate DataSet SaveDelegate(object pk, DataSet delta); // defined in TaskAttribute
public abstract class MiddleTier : MarshalByRefObject
{
[Task("Invoice", SaveDelegate)]
public abstract Invoice_Save(object pk, DataSet delta);
[Task("Receipt", SaveDelegate)]
// it's nice if the compiler can flag an error
public abstract Receipt_Save(object pk, object[] delta);
}
}
Я думаю, что если поместить методы в каждый класс, было бы излишним всегда создавать экземпляр объекта Remoting. Поместив их в отдельный класс, было бы сложнее облегчить повторное использование кода, скажем, Invoice_Save нужна некоторая информация о Receipt_Open. На самом деле у меня даже есть отчет (кристалл), в котором извлекаются данные из Remoting промежуточного DataSet, внутри вызванного метода, он получает некоторую информацию о других методах и объединяется в свой собственный DataSet, все они происходят на промежуточном уровне, а не в нескольких обходах все делается на стороне сервера (средний уровень)