Обычно система счетов должна делать снимок счета и всех его отношений.Причина - изменения в компании.Например:
- Если изменение цены товара не должно повлиять на уже обработанные счета
- Если товар снят с производства, он не должен влиять на уже обработанные счета
- Если клиент изменит егоадрес, по которому он не должен влиять на уже обработанные счета
- и т. д.
В счете-фактуре всегда должны отображаться данные в состоянии системы со дня создания счета-фактуры.Вы можете добиться этого либо с помощью некоторого уровня денормализации для таблиц счетов-фактур и элементов счетов-фактур, либо с помощью массива каждой записи, связанной со счетом-фактурой.
Теперь, как мне кажется, я могу использовать преимущества XML вТаблица?Я могу сохранить счет с любыми полями как xml.
Да, вы можете, но для структуры сущностей это поле будет просто строкой, поскольку оно не понимает тип данных SQL XML.
Linq-to-XML не медленный.
Linq-to-XML не имеет значения, потому что Linq-to-XML - это .NET-функция для запроса загруженного XML-документа.Он будет запрашивать XML-документы, хранящиеся на сервере SQL, если вы не загрузите все счета с вашего сервера SQL в ваше приложение и не выполните запрос Linq-to-XML в памяти вашего приложения.Это медленно, на самом деле это убийца вашего приложения.
Чтобы запрашивать данные XML на сервере SQL, вы должны использовать собственный SQL с его функциями XML (XPath, XQuery).Это вопрос для ребят из SQL, как XML и запросы XML влияют на общую производительность ваших запросов и насколько это соответствует вашим потребностям.
При изменениях я обновляю только свой Business.dll и не DALтребуется изменение.
Вряд ли.Вам также придется обновить ваш DAL, потому что все ваши SQL-запросы, запрашивающие ваши XML-файлы, будут размещены там.Если у вас не будет очень сложной структуры данных для настройки приложения для нового типа счета (включая полную настройку пользовательского интерфейса, поскольку новые поля могут иметь новые правила и проверки, это могут быть поля со списком, заполненные из другого источника данных и т. Д.), Вам придетсятакже обновите пользовательский интерфейс.
Какие есть варианты?
- Использование XML и удаление EF
- Использование EF и разработка приложения таким образом, чтобы при каждом создании нового типа счета вам приходилось добавлять небольшой фрагмент кода в DAL, BLL и UIподдержать это.Например, могут быть определены критерии, согласно которым приложение должно быть спроектировано таким образом, чтобы в течение 5-10 мд добавлялся новый тип счета.Я использовал этот способ в приложении обратного типа, в котором обрабатывались заказы (но в конце мы обнаружили, что невозможно выполнить бизнес-требования в отведенное время, поскольку каждый новый тип заказа содержит так много новых требований, включая интеграцию с новыми внешними источниками данных, чтотребуется отдельная версия проекта).
- Используйте EF с виртуальной расширяемостью.Каждый ваш счет-фактура и позиция счета-фактуры будут содержать X дополнительных полей (вы можете использовать для них разные типы или просто строку - это зависит от ваших ожиданий).Эти поля будут использоваться для настройки.Вам также понадобятся некоторые таблицы конфигурации, в которых будет указано, какие типы счетов-фактур использует какие поля, какие проверки для этих полей и каковы имена интерфейсов и порядок этих полей.Я видел, как эта система успешно используется с 5 строковыми полями в накладной и 5 строковыми полями в строке накладной.
- Используйте EF и фиксированные таблицы для счетов-фактур и строк счетов-фактур, содержащих только данные, общие для всех типов счетов-фактур.Используйте дополнительные таблицы для содержания дополнительных полей и таблиц конфигурации для описания типов полей.В вашем приложении не используйте отражение, а вместо этого работайте с дополнительными полями, как со словарем (ключ, набор значений).Это довольно распространенная структура для простой расширяемости.
Ни один из предыдущих случаев не решит всех проблем, которые могут возникнуть с новым типом счета. Например, если новое поле - это некоторая реляционная зависимость от другого поля, расширенная проверка бизнеса или требуются некоторые внешние данные, это действительно не будет решено.
Возможно создание полностью универсальной системы, принимающей счета любого типа, которые они когда-либо создают, но сложность и цена этой системы будут как минимум в 10 раз выше. Это также повлияет на время доставки приложения. Сложность также будет влиять на удобство использования, потому что приложению потребуется очень тщательный дизайн UX, чтобы быть простым в использовании.
Это типичный сбой в управлении проектом, когда цена требований не сообщается правильно, и поэтому ожидания от проекта намного больше, чем позволяет бюджет. Также кошмаром является разработка проекта для бизнеса, который не имеет оптимизированных бизнес-процессов и просто следует за хаосом.
Я видел проекты, в которых ожидалось, что сейчас будет одно приложение, которое будет обслуживать (без какой-либо дополнительной разработки) все возможные будущие случаи, не зная, как эти случаи будут определены. Конечно, бюджета всегда было достаточно, чтобы поставить известные на данный момент дела. Все эти проекты не соответствовали этому требованию.
Btw. чтобы убедиться, что вы охватили как можно больше дел, вам не следует работать со всеми текущими типами счетов-фактур с самого начала. Просто позвольте вашему аналитику собрать минимальный набор полей для каждого типа счета и работать с ними. Все реальные типы счетов должны быть настроены через вашу систему, а не жестко закодированы.