Если вы пытаетесь создать табличный шлюз для существующей таблицы из 100 столбцов для этой другой службы, список или словарь могут быть довольно быстрым способом начать работу. Однако, если вы принимаете входные данные из мастера больших форм или пользовательского интерфейса, вам, вероятно, придется проверить содержимое перед отправкой в удаленную службу.
Простой DTO может выглядеть так:
class Form
{
public $stuff = array();
function add( $key, $value ) {}
}
Шлюз таблицы может быть больше похож на:
class Form
{
function findBySubmitId( $id ) {} // look up my form
function saveRecord() {} // save it for my session
function toBillingInvoice() {} // export it when done
}
И вы можете продлить это довольно легко в зависимости от того, есть ли у вас варианты счета. (Добавление метода validate () для каждого подкласса может быть целесообразным.)
class TPSReport extends Form {
function validate() {}
}
Если вы хотите отделить ваш DTO от механизма доставки, потому что механизм доставки является общим для всех ваших счетов, это может быть легко. Однако вы можете оказаться в ситуации, когда существует бизнес-логика в отношении успеха или неудачи счета. И это то, где я продолжаю уходить в сорняки. Но это где и модель ОО может быть полезна ... Я буду платить копейки, что будут разные счета-фактуры и разные процедуры для разных счетов-фактур, и если barfs отправки счетов-фактур, вам потребуются дополнительные процедуры: -)
class Form {
function submitToBilling() {}
function reportFailedSubmit() {}
function reportSuccessfulSubmit() {}
}
class TPSReport extends Form {
function validate() {}
function reportFailedSubmit() { /* oh this goes to AR */ }
}
Обратите внимание, ответ Дэвида Лайвлиса: это хорошее понимание. Часто поля формы имеют свои собственные структуры данных и свои правила проверки. Таким образом, вы можете моделировать составные объекты довольно быстро. Это будет связывать каждый тип поля с его собственными правилами проверки и обеспечивать более строгую типизацию.
Если вам действительно нужно углубиться в валидацию, часто бизнес-правила полностью отличаются от моделей или DTO, которые их предоставляют. Вы также можете столкнуться с логикой, которая ориентирована на отдел и имеет мало общего с формой. Важно не допустить, чтобы это валидировало саму форму и процесс (ы) отправки модели.
Если вы организуете схему за этими формами, вместо таблицы с 100 столбцами, вы, вероятно, разбили бы записи по идентификаторам полей и значениям на несколько столбцов.
table FormSubmissions (
id int
formVer int -- fk of FormVersions
formNum int -- group by form submission
fieldName int -- fk of FormFields
fieldValue text
)
table FormFields (
id int
fieldName char
)
table FormVersions (
id
name
)
select s.* f.fieldName from FormSubmissions s
left join FormFields f on s.fieldName = f.id
where formNum = 12345 ;
Я бы сказал, что это определенно тот случай, когда вы захотите пересмотреть свой путь, пока не найдете что-то удобное. Надеюсь, у вас есть некоторый контроль над такими вещами, как схема и ваша объектная модель. (Кстати ... эта таблица известна как «нормализованная»? Я видел изменения в этой схеме, обычно организованные по типу данных ... хорошо?)