格式化文件的好方法

发布于 2024-10-22 18:26:59 字数 541 浏览 5 评论 0原文

在我的工作中,我需要格式化付款文件以便能够与银行进行通信。问题是所有银行都要求不同的格式。现在,我们使用模板方法模式 [GOF] 尝试尽可能以泛型的方式做到这一点,但结果是每种格式都会重复相同的 3 个类。

继承自 asbtract absPaymentFile 的类(具有控制反转) 继承自 Payment 的类(包含有关付款的信息,有时具有 1 或 2 个与其他付款类不同的属性) 继承自absMerchant的类(包含有关商家的信息和一些实现方法)

是否有一种方法可以用“几乎”相同的信息来格式化文件,在某些方面比我们现在所做的更好?

此链接应该为您提供我需要做的事情的良好基线: https ://www.vancity.com/lang/fr/SharedContent/documents/CPA_Std005_Specs.doc

这是一个 .doc !

谢谢 !

At my job, I need to format payments file to be able to communicate with banks. The problem is that all bank ask for a different format. Right now, we use the Template Method pattern [GOF] in a attempt to do this as generics as possible but in result of the same 3 classes repeat for every format.

a class inherit from asbtract absPaymentFile (with Inversion of Control)
a class inherit from Payment (contain info about the payment sometime have 1 or 2 attribute different of the others payments classes)
a class inherit from absMerchant (contain info about the merchant and some method to implement)

Is there a way to format a file, with "almost" the same information, in several ways better than what we do now ?

this link should provide you a good base line of what i need to do : https://www.vancity.com/lang/fr/SharedContent/documents/CPA_Std005_Specs.doc

It's a .doc !

Thanks !

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

眼眸印温柔 2024-10-29 18:26:59

在尝试制作一些只需要进行细微调整即可支持多种格式的东西之后,我想说不要这样做。 DRY 原则在这里并不适用,因为每种新格式确实独立于其他格式,并且可能会发生变化。

是的,这可能意味着复制/粘贴相当数量的代码,但老实说,一旦完成一种格式,那么在接收软件更新其规范之前,您不必担心它。另外,如果该格式发生更改,您通常不希望这些更改影响您的其他输出代码。

简而言之,这是应该只封装到具有某种类型的插件架构的领域之一。这意味着,所有类都应该实现一个基本接口,该接口简单地定义了主应用程序将如何向其传输数据。之后,这些类应该能够彼此显着不同,并且其中一个类的更新应该不会对其他类产生影响。

Having gone down the path of trying to make something which would only need minor tweaks to support multiple formats, I'd say don't. DRY principles don't really apply here because each new format is really and truly independent of the others and may change.

Yes, it might mean copy/pasting fair amounts of code but honestly once one format is done then you don't have to worry about it until the receiving software updates their spec. Also, if that format changes you usually don't want any of those changes to impact your other output code.

In short, this is one of those areas that should only be encapsulated to the point of having some type of plugin architecture. Meaning, all of the classes should implement a basic interface that simply defines how your main app is going to transfer data to it. After that the classes should be able to diverge significantly from each other AND updates in one should have no impact in others.

柠栀 2024-10-29 18:26:59

我会考虑使用 C# 库支持的格式,例如 XML 或 JSON 这样你就不必读取或写入文件时重新发明轮子。上述两种格式都允许您拥有可选属性。例如

<elements>
    <element name="name1" value1="somevalue" company1specific="something" />
    <element name="name1" value1="somevalue" specificToAnotherCompany="something" />
</element>

{
    "elements" : [
        { "name":"name1", "company1specific":"something" },
        { "name":"name1", "specificToAnotherCompany":"something" }
    ]
}

希望这有帮助。

I would look into using a format supported by a C# library such as XML or JSON so you don't have to reinvent the wheel when reading or writing the file. Both of the mentioned formats would allow you to have optional attributes. For example

<elements>
    <element name="name1" value1="somevalue" company1specific="something" />
    <element name="name1" value1="somevalue" specificToAnotherCompany="something" />
</element>

or

{
    "elements" : [
        { "name":"name1", "company1specific":"something" },
        { "name":"name1", "specificToAnotherCompany":"something" }
    ]
}

Hope this helps.

北方的韩爷 2024-10-29 18:26:59

如果使用平面文件格式,请查看此库:http://www.filehelpers.com/ 。该库将允许您使用具有类和成员属性的类来表示格式。

此外,在这种粒度级别上,很容易被重用冲昏头脑。如果生成文件格式不是您正在处理的核心内容,那么更重要的是要关注更高级别的体系结构,而不是文件生成中的可重用性。此外,保持格式化例程彼此隔离可能会有所帮助,以便一种格式的更改不会影响另一种格式。合并单元测试将进一步提高可维护性。

If flat file formats are being used take a look at this library: http://www.filehelpers.com/. The library will allow you to represent a format using a class with class and member attributes.

Also, it is easy to get carried away with re-use at this level of granularity. If generating file formats is not the core of what you're working on, it is more important to pay attention to architecture at a higher level then re-usability in file generation. Moreover, it might be helpful to keep formatting routines isolated from each other, so that changes for one format do not affect the other. Incorporating unit tests will further improve maintainability.

你是暖光i 2024-10-29 18:26:59

您需要一个内部“主格式”,然后需要一个 DocumentConverter 来获取 MasterFormatFile 并将其转换为所需的输出。

使 MasterFormatFile 公开一个通用 api,几乎就像作为字典获取键值,但有一些其他支持。

扩展到新的 FileFormatter 将变得简单且模块化。

You need an internal "Master Format" and then a DocumentConverter that takes the MasterFormatFile and converts it to the desired output.

Make the MasterFormatFile expose a generic api, almost like a get key-value as a Dictionary but with some other support.

Extending to a new FileFormatter Will be easy and modular.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文