Здравствуйте, sereginseregin, Вы писали:

SP>>... подробнее развернуть слой Представление, но куда и как — плохо понимаю. Подскажите пожалуйста.
S>А на что у Вас на картинке прямоугольник с надписью "Интерфейс пользователя" — вот его и разверните для каждой сущности.
Вот это до меня и не доходит пока Что именно описывать? Формы, какие будут в приложении? Или иерархию наследования форм?


S>Хочу еще добавить:
S>1. ИМХО, Ваш подход, когда один контролер для нескольких документов на практике не масштабируем. На Ваши 2 документа вы описали 10 функций, соответственно на 100-200 документов будет около 2000 функций. Рассмотрите Вашу идеологию MVC отдельно для каждого документа и затем объедините полученные модели минимальными связями.
Спасибо, подумаю над этим.


S>2. Ваши проверки:
SP>>1. Введенная дата счета не больше текущей даты;
SP>>2. Введенная дата накладной не больше даты счета и не больше текущей даты;
SP>>3. При сохранении документов табличная часть не должна быть пустой;
SP>>4. При редактировании накладной не можем изменять поле грузоотправитель.
S> на практике также не имеют особого смысла. Хозяйственные операции между продавцом и покупателем ведутся в договорной форме, сделка может быть сложной и проходить в длинный промежуток времени, счета и накладные могут многократно перевыставляться. Наше хаконодательство несовершенно, придумывать свои ограничения, даже если они кажутся логичными — это вставлять палки Бухгалтеру. Для начала рассмотрите только те ограничения, которые требуются законодательно, например в Положениях по бухгалтерскому учету (ПБУ), остальное бухгалтер проконтролирует сам, или даст замечания на доработку.
Спасибо за замечания, учту. Сейчас надо просто нарисовать как написано, а оптимизация будет потом.


И еще вопрос — нужно ли объектам документов быть синглтонами?