Send the query to the factory, which grabs the struct from the library. Then have it read the struct and put it into any object you want. The factory then returns the object.
An alternative is to use an adapter. Instead of just reading each field in the struct and using it to construct your model object, you might create an adapter object which contains the struct and presents the desired interface to the rest of the code. Your factory could then handle the query and return an adapted struct.
I'd shy away from the Decorator pattern. It isn't a bad pattern, but it is far more useful when you need to dynamically add or remove behavior. In this case, you haven't mentioned the need to do this dynamically, so Decorator is overkill.
On the database side, a simple data access object (DAO) will allow you to pass your model object to one of the CRUD methods. It's not the most elegant solution, but it sounds like you don't need the extra elegance of a JDO type solution.
I would start with base classes for commands and responses and each specific command or response derives from those.
Then a class for sending and receiving - either the command knows how to serialize itself or another paired object can do that if you want to really decouple things.
Some factory object would create the proper response type object based on parsing the response (perhaps along with knowledge of the last sent request/command)
The response object ctor takes the struct response as a parameter.
You then make a database/persistence object that knows how to tell the objects to save themselves (or you have a pairing of response objects to persistence objects for more decoupling)
There are probably better ways to do it, but the above seems reasonable to me and a lot of this I did for writing an rs232 application that talked to a medical lab device.
Not sure if this could be covered by one single pattern. And actually I don't think it's a good approach to pick a design pattern and then implement it.
By "encapsulate the entire process", I mean the process of sending a command to the device, reading the data from the device (I know the struct definition that would be returned), then converting it to an object using a class with a definition similar to the struct ( I will use the same class later for reading the records from the db) and saving the results to the db.
Btw Tim's answer is more in line with what I'm doing.
// CALLER
public class Program
{
static void Main(string[] args)
{
Device<Command1, S1> cmd1 = new Device<Command1, S1>();
S1 s1 = cmd1.ExecuteCommand(new Command1());
Device<Command2, S2> cmd2 = new Device<Command2, S2>();
S2 s2 = cmd2.ExecuteCommand(new Command2());
}
}
// SDK
public interface ICommand<T>
{
T Execute();
}
public struct S1
{
public int id;
}
public struct S2
{
public string name;
}
public class Command1 : ICommand<S1>
{
public S1 Execute()
{ return new S1() { id = 1 }; }
}
public class Command2 : ICommand<S2>
{
public S2 Execute()
{ return new S2() { name = "name" }; }
}
// DEVICE
public class Device<T, U> where T : ICommand<U>
{
public U ExecuteCommand(T cmdObject)
{
return cmdObject.Execute();
}
}
I had this problem before, I did a little hack using interfaces and generics and managed to do it:
// CALLER
public class Program
{
static void Main(string[] args)
{
Device<Command1, S1> cmd1 = new Device<Command1, S1>();
S1 s1 = cmd1.ExecuteCommand(new Command1());
Device<Command2, S2> cmd2 = new Device<Command2, S2>();
S2 s2 = cmd2.ExecuteCommand(new Command2());
}
}
// SDK
public interface ICommand<T>
{
T Execute();
}
public struct S1
{
public int id;
}
public struct S2
{
public string name;
}
public class Command1 : ICommand<S1>
{
public S1 Execute()
{ return new S1() { id = 1 }; }
}
public class Command2 : ICommand<S2>
{
public S2 Execute()
{ return new S2() { name = "name" }; }
}
// DEVICE
public class Device<T, U> where T : ICommand<U>
{
public U ExecuteCommand(T cmdObject)
{
return cmdObject.Execute();
}
}
发布评论
评论（5）
使用工厂。
将查询发送到工厂，工厂从库中获取结构。然后让它读取结构并将其放入您想要的任何对象中。然后工厂返回该对象。
另一种方法是使用适配器。您可以创建一个包含该结构并向其余代码提供所需接口的适配器对象，而不是仅仅读取结构中的每个字段并使用它来构造模型对象。然后，您的工厂可以处理查询并返回调整后的结构。
我会回避装饰者模式。这不是一个坏模式，但当您需要动态添加或删除行为时，它会更有用。在这种情况下，您没有提到需要动态执行此操作，因此装饰器是多余的。
在数据库方面，一个简单的数据访问对象 (DAO) 将允许您将模型对象传递给其中一个 CRUD 方法。这不是最优雅的解决方案，但听起来您不需要 JDO 类型解决方案的额外优雅。
Use a factory.
Send the query to the factory, which grabs the struct from the library. Then have it read the struct and put it into any object you want. The factory then returns the object.
An alternative is to use an adapter. Instead of just reading each field in the struct and using it to construct your model object, you might create an adapter object which contains the struct and presents the desired interface to the rest of the code. Your factory could then handle the query and return an adapted struct.
I'd shy away from the Decorator pattern. It isn't a bad pattern, but it is far more useful when you need to dynamically add or remove behavior. In this case, you haven't mentioned the need to do this dynamically, so Decorator is overkill.
On the database side, a simple data access object (DAO) will allow you to pass your model object to one of the CRUD methods. It's not the most elegant solution, but it sounds like you don't need the extra elegance of a JDO type solution.
我将从命令和响应的基类开始，每个特定的命令或响应都派生自这些基类。
然后是一个用于发送和接收的类 - 如果您想真正解耦事物，命令知道如何序列化自身，或者另一个配对对象可以做到这一点。
某些工厂对象会根据解析响应（可能还知道最后发送的请求/命令）来创建正确的响应类型对象
。响应对象构造函数将结构响应作为参数。
然后，您创建一个知道如何告诉对象保存自身的数据库/持久性对象（或者您有一对响应对象与持久性对象以实现更多解耦）
可能有更好的方法来做到这一点，但上述对我来说似乎是合理的我所做的很多工作是为了编写一个与医疗实验室设备通信的 rs232 应用程序。
I would start with base classes for commands and responses and each specific command or response derives from those.
Then a class for sending and receiving - either the command knows how to serialize itself or another paired object can do that if you want to really decouple things.
Some factory object would create the proper response type object based on parsing the response (perhaps along with knowledge of the last sent request/command)
The response object ctor takes the struct response as a parameter.
You then make a database/persistence object that knows how to tell the objects to save themselves (or you have a pairing of response objects to persistence objects for more decoupling)
There are probably better ways to do it, but the above seems reasonable to me and a lot of this I did for writing an rs232 application that talked to a medical lab device.
不确定这是否可以用一种模式来涵盖。实际上，我认为选择一种设计模式然后实现它并不是一个好方法。
除此之外，我认为您可能想研究责任链图案。也许是 装饰器 模式。
Not sure if this could be covered by one single pattern. And actually I don't think it's a good approach to pick a design pattern and then implement it.
Apart from that, I think you might want to look into the Chain of Responsibility pattern. Maybe the Decorator pattern.
@Ryan Elkins
通过“封装整个过程”，我的意思是向设备发送命令、从设备读取数据的过程（我知道将返回的结构定义），
然后使用具有与结构类似的定义的类将其转换为对象（稍后我将使用相同的类从数据库读取记录）
并将结果保存到数据库。
顺便说一句，蒂姆的回答更符合我正在做的事情。
感谢您的回复
@Ryan Elkins
By "encapsulate the entire process", I mean the process of sending a command to the device, reading the data from the device (I know the struct definition that would be returned),
then converting it to an object using a class with a definition similar to the struct ( I will use the same class later for reading the records from the db)
and saving the results to the db.
Btw Tim's answer is more in line with what I'm doing.
Thanks for the responses
我以前遇到过这个问题，我使用接口和泛型做了一些修改并设法做到了：
I had this problem before, I did a little hack using interfaces and generics and managed to do it: