另一种策略是简单的类，它执行 Debug.WriteLine< /code> 调用，这样您就不需要在开发过程中将现金提取连接到您的 PC
，例如
public class ComPortCashDrawer : ICashDrawer
{
public void Open()
{
// open via COM port etc
}
}
public class DebugWriterCashDrawer : ICashDrawer
{
public void Open()
{
Debug.WriteLine("DebugWriterCashDrawer.Open() @ " + DateTime.Now);
}
}
同样，对于打印，您有一个获取数据的打印接口：
public interface IRecieptPrinter
{
bool Print(object someData);
}
然后您可以进行一个或多个实现。
基本打印机
专用标签打印机
一种基于文本的打印机，可保存到文件中...
例如，
public class BasicRecieptPrinter : IRecieptPrinter
{
public bool Print(object someData)
{
// format for a basic A4 print
return true; // e.g. success etc
}
}
public class SpecificXyzRecieptPrinter : IRecieptPrinter
{
public bool Print(object someData)
{
// format for a specific printer
return true; // e.g. success etc
}
}
public class PlainTextFileRecieptPrinter : IRecieptPrinter
{
public bool Print(object someData)
{
// Render the data as plain old text or something and save
// to a file for development or testing.
return true; // e.g. success etc
}
}
var printer = container.Resolve<IRecieptPrinter>();
PK:-)
This is probably a slightly different answer to what you were looking for(!)...
When working with "external interfaces" (e.g. printers, cash draws etc) always abstract things. You probably want to implement strategies - Pattern Strategy.
You make an interface for the cash draw:
public interface ICashDrawer
{
void Open();
}
The provide implementations:
one strategy is a class that uses COM to open the draw
another is something as simple as a class that does a Debug.WriteLine call so you don't need a cash draw connected to your PC during development
e.g.
public class ComPortCashDrawer : ICashDrawer
{
public void Open()
{
// open via COM port etc
}
}
public class DebugWriterCashDrawer : ICashDrawer
{
public void Open()
{
Debug.WriteLine("DebugWriterCashDrawer.Open() @ " + DateTime.Now);
}
}
Again for printing you have a print interface that takes the data:
public interface IRecieptPrinter
{
bool Print(object someData);
}
then you make one or more implementations.
Basic printer
Specialized label printer
a text based one that saves to a file...
e.g.
public class BasicRecieptPrinter : IRecieptPrinter
{
public bool Print(object someData)
{
// format for a basic A4 print
return true; // e.g. success etc
}
}
public class SpecificXyzRecieptPrinter : IRecieptPrinter
{
public bool Print(object someData)
{
// format for a specific printer
return true; // e.g. success etc
}
}
public class PlainTextFileRecieptPrinter : IRecieptPrinter
{
public bool Print(object someData)
{
// Render the data as plain old text or something and save
// to a file for development or testing.
return true; // e.g. success etc
}
}
With respect to the SDK, if down the track you find you need it for some reason you write implementations using the SDK. Over time you may end up with several ways to interface with different external devices. The client may get a new cash draw one day etc etc.
Is that clear, I can flesh out what I mean if you want but you probably get my drift.
Your app sets itself up with the respective implementations at startup, you may want to take a look at Dependency injection as well and you will find things easier if you use a container to resolve the types.
var printer = container.Resolve<IRecieptPrinter>();
第一种操作是向打印机端口发送控制代码（打印机希望忽略该控制代码并且不会吐出整卷收据纸），而对于第二种，您需要执行 COM 端口通信操作。无论哪种情况，控制代码都依赖于硬件。大多数时候它们可以在用户手册中找到，但有时技术作家那天感觉特别邪恶，你就必须去网上挖掘。
I've never dealt programmatically with what you're asking, but I do have some experience when it comes to POS systems which may help you.
What you do for printing and for the cash drawer are highly dependent on the hardware you're working with. And there is a wide variety of hardware out there.
In every POS system I've seen, there are multitudes of drivers for every conceivable receipt printer and cash drawer, so unless you're developing a full-blown system, just concentrate on the specific hardware you're going to be working with. Even then, try to factor your code well so that you maximize the benefit of the strategy pattern. If you're working with more than one type of device, you'll thank yourself later for implementing it that way.
For printing, there are 3 fundamental types of printers you may encounter:
Receipt printer that can only print text (antiquated, but still around)
Receipt printer that can print graphics
A standard printer printing 8.5" x 11" full-page invoices/credit memos (easy, 'nuff said)
I believe most, if not all, modern receipt printers fall into category #2, but you could run into a legacy system using a printer from category #1.
For category #2, you should be able to use the standard .NET printing interface. The only issue may be sending a control code to activate the cutting mechanism (if equipped) at the appropriate time(s); or, the printer driver may do it automatically based on the paper length specified in the printing algorithm. Again, I've never tried this, but if you have access to a receipt printer, you should be able to figure this stuff out in a hurry.
If you're dealing with a single client who has a printer in category #1, you can make a good argument that it will be less expensive to buy a new printer in category #2 than it will be to pay you to develop a dead-end driver to print on their existing hardware.
For cash drawers, I'm less familiar than with printers, but I know of two options as far as communication and hardware arrangement:
Attaches via LPT port through the printer. (Cable chain: computer --> printer --> cash drawer)
Attached directly to the computer, either by a COM/LPT port or probably USB in a modern one.
The first kind operates by sending control codes to the printer port (which the printer would hopefully ignore and not spit out an entire roll of receipt paper), while for the second you'll need to do the COM port communication stuff. In either case, the control codes are hardware-dependent. Most of the time they're found in the user manual, but sometimes the technical writer was feeling particularly evil that day, and you'll have to go digging online.
快速浏览一下，MS 销售点系统基于 Window Embedded，这实际上只是获得更低单位成本和更小 Windows 操作系统许可证的一种方式。似乎有一些特定于 POS 的 API，但您似乎想要推出自己的 API，您可能仍然想以某种方式使用 Windows Embedded。安全可能是第一要务。
From just a quick browse the MS point-of-sale system is based on Window Embedded which is really just a way to get a lower cost per unit and smaller Windows OS license. It seems there are some APIs specific to POS, but you seem to want to roll your own, you'll still probably want to use Windows Embedded in some way. Security will probably be job 1.
To control the receipt printer directly, read up on the ESC/POS commands. These commands will allow you to open the cash drawer and print barcodes and images on the receipts.
发布评论
评论（4）
这可能与您正在寻找的答案略有不同（！）...
当使用“外部接口”（例如打印机、现金提取等）时，总是抽象的东西。您可能想要实施策略 - 模式策略。
您为现金抽取创建一个接口：
提供实现：
Debug.WriteLine< /code> 调用，这样您就不需要在开发过程中将现金提取连接到您的 PC，例如
同样，对于打印，您有一个获取数据的打印接口：
然后您可以进行一个或多个实现。
例如，
对于 SDK，如果您发现由于某种原因需要它，则可以使用 SDK 编写实现。随着时间的推移，您最终可能会采用多种方式与不同的外部设备进行交互。有一天，客户可能会获得新的现金提款，等等。
清楚了吗，如果您愿意，我可以充实我的意思，但您可能明白我的意思。
您的应用程序在启动时会自行设置相应的实现，您可能需要查看依赖注入 同样，如果您使用 容器 来解析类型，您会发现事情变得更容易。
PK:-)
This is probably a slightly different answer to what you were looking for(!)...
When working with "external interfaces" (e.g. printers, cash draws etc) always abstract things. You probably want to implement strategies - Pattern Strategy.
You make an interface for the cash draw:
The provide implementations:
Debug.WriteLinecall so you don't need a cash draw connected to your PC during developmente.g.
Again for printing you have a print interface that takes the data:
then you make one or more implementations.
e.g.
With respect to the SDK, if down the track you find you need it for some reason you write implementations using the SDK. Over time you may end up with several ways to interface with different external devices. The client may get a new cash draw one day etc etc.
Is that clear, I can flesh out what I mean if you want but you probably get my drift.
Your app sets itself up with the respective implementations at startup, you may want to take a look at Dependency injection as well and you will find things easier if you use a container to resolve the types.
PK :-)
我从来没有以编程方式处理过你所问的问题，但我在 POS 系统方面确实有一些经验，这可能会对你有所帮助。
您对打印和钱箱所做的工作很大程度上取决于您所使用的硬件。硬件种类繁多。
在我见过的每个 POS 系统中，每种可以想象的收据打印机和现金抽屉都有大量的驱动程序，因此除非您正在开发一个成熟的系统，否则只需专注于您将使用的特定硬件。即便如此，请尝试很好地分解您的代码，以便最大限度地发挥策略模式的优势。如果您使用不止一种类型的设备，您稍后会感谢自己以这种方式实现它。
对于打印，您可能会遇到 3 种基本类型的打印机：
我相信大多数（如果不是全部）现代收据打印机都属于类别#2，但您可能会使用类别#1 的打印机遇到遗留系统。
对于类别 #2，您应该能够使用标准 .NET 打印接口。唯一的问题可能是发送控制代码以在适当的时间激活切割机构（如果配备）；或者，打印机驱动程序可以根据打印算法中指定的纸张长度自动执行此操作。再说一次，我从来没有尝试过这个，但是如果您可以使用收据打印机，您应该能够快速解决这些问题。
如果您正在与拥有第 1 类打印机的单个客户打交道，您可以提出一个很好的论据，即购买第 2 类新打印机比支付您开发一个死机要便宜。 -end 驱动程序可在其现有硬件上进行打印。
对于现金抽屉，我不像打印机那么熟悉，但就通信和硬件布置而言，我知道有两种选择：
第一种操作是向打印机端口发送控制代码（打印机希望忽略该控制代码并且不会吐出整卷收据纸），而对于第二种，您需要执行 COM 端口通信操作。无论哪种情况，控制代码都依赖于硬件。大多数时候它们可以在用户手册中找到，但有时技术作家那天感觉特别邪恶，你就必须去网上挖掘。
I've never dealt programmatically with what you're asking, but I do have some experience when it comes to POS systems which may help you.
What you do for printing and for the cash drawer are highly dependent on the hardware you're working with. And there is a wide variety of hardware out there.
In every POS system I've seen, there are multitudes of drivers for every conceivable receipt printer and cash drawer, so unless you're developing a full-blown system, just concentrate on the specific hardware you're going to be working with. Even then, try to factor your code well so that you maximize the benefit of the strategy pattern. If you're working with more than one type of device, you'll thank yourself later for implementing it that way.
For printing, there are 3 fundamental types of printers you may encounter:
I believe most, if not all, modern receipt printers fall into category #2, but you could run into a legacy system using a printer from category #1.
For category #2, you should be able to use the standard .NET printing interface. The only issue may be sending a control code to activate the cutting mechanism (if equipped) at the appropriate time(s); or, the printer driver may do it automatically based on the paper length specified in the printing algorithm. Again, I've never tried this, but if you have access to a receipt printer, you should be able to figure this stuff out in a hurry.
If you're dealing with a single client who has a printer in category #1, you can make a good argument that it will be less expensive to buy a new printer in category #2 than it will be to pay you to develop a dead-end driver to print on their existing hardware.
For cash drawers, I'm less familiar than with printers, but I know of two options as far as communication and hardware arrangement:
The first kind operates by sending control codes to the printer port (which the printer would hopefully ignore and not spit out an entire roll of receipt paper), while for the second you'll need to do the COM port communication stuff. In either case, the control codes are hardware-dependent. Most of the time they're found in the user manual, but sometimes the technical writer was feeling particularly evil that day, and you'll have to go digging online.
快速浏览一下，MS 销售点系统基于 Window Embedded，这实际上只是获得更低单位成本和更小 Windows 操作系统许可证的一种方式。似乎有一些特定于 POS 的 API，但您似乎想要推出自己的 API，您可能仍然想以某种方式使用 Windows Embedded。安全可能是第一要务。
From just a quick browse the MS point-of-sale system is based on Window Embedded which is really just a way to get a lower cost per unit and smaller Windows OS license. It seems there are some APIs specific to POS, but you seem to want to roll your own, you'll still probably want to use Windows Embedded in some way. Security will probably be job 1.
要直接控制收据打印机，请阅读 ESC/POS 命令。这些命令将允许您打开现金抽屉并在收据上打印条形码和图像。
但是，当您使用 C# 时，使用 Microsoft 服务点可能更容易类库。
To control the receipt printer directly, read up on the ESC/POS commands. These commands will allow you to open the cash drawer and print barcodes and images on the receipts.
However, as your using C#, it maybe be easier to use the Microsoft Point of Service class library.