AOP、DataMappers 和工厂，它们可以一起工作吗？
平台：C#2.0 使用：Castle.DynamicProxy2
我已经奋斗了大约一周，试图找到一个好的策略来重写我的 DAL。 我尝试过 NHibernate，不幸的是，它不太适合我的项目。 因此，到目前为止，我已经提出了这种交互：
我首先从注册我的 DTO 和数据映射器开始：
MetaDataMapper.RegisterTable(typeof(User)):
MapperLocator.RegisterMapper(typeof(User), typeof(UserMapper));
这将映射每个 DTO，因为它本质上是使用 DTO 属性上的自定义属性注册的：
[Column(Name = "UserName")]
然后我有一个属于的映射器对于每个 DTO，因此对于这种类型，它将是 UserMapper。 该数据映射器负责调用我的 ADO.Net 包装器，然后将结果映射到 DTO。 然而，我正在启用深度加载和随后的延迟加载，因此我陷入了困境。 基本上，我的用户 DTO 可能有一个地址对象 (FK)，它需要另一个映射器来填充该对象，但我必须确定在运行时使用地址映射器。
我的问题是处理类型，而无需每次需要确定要返回哪个映射器时显式地遍历它们的列表（更不用说总是必须保持该列表更新的头痛）。 所以我的解决方案是拥有一个我注册的 MapperLocator 类（如上所述）并返回我的所有数据映射器实现的 IDataMapper 接口。 然后，如果我正在处理 User 对象，我可以将其转换为 UserMapper 类型。 然而，当我尝试确定在运行时返回的数据映射器的类型时，这并不那么容易。 由于泛型必须在编译时知道它们是什么，因此如果不使用反射，则无法选择使用 AOP，然后在运行时传入类型。 当我将 DTO 映射到表、读取属性等时，我已经做了相当多的反思。 另外，我的 MapperFactory 使用反射来实例化正确的数据映射器。 因此，我试图不假思索地做到这一点，以尽可能减少那些昂贵的电话。
我认为可以通过传递接口来找到解决方案，但我还没有能够实现这个想法。 所以后来我认为解决方案可能是使用委托，但我也不知道如何实现这个想法。 所以...坦白说...我迷路了，你能帮忙吗？
Platform: C# 2.0
Using: Castle.DynamicProxy2
I have been struggling for about a week now trying to find a good strategy to rewrite my DAL. I tried NHibernate and, unfortunately, it was not a good fit for my project. So, I have come up with this interaction thus far:
I first start with registering my DTO's and my data mappers:
MetaDataMapper.RegisterTable(typeof(User)):
MapperLocator.RegisterMapper(typeof(User), typeof(UserMapper));
This maps each DTO as it is registered using custom attributes on the properties of the DTO essentially:
[Column(Name = "UserName")]
I then have a Mapper that belongs to each DTO, so for this type it would be UserMapper. This data mapper handles calling my ADO.Net wrapper and then mapping the result to the DTO. I however am in the process of enabling deep loading and subsequently lazy loading and thus where I am stuck. Basically my User DTO may have an Address object (FK) which requires another mapper to populate that object but I have to determine to use the AddressMapper at run time.
My problem is handling the types without having to explicitly go through a list of them (not to mention the headache of always having to keep that list updated) each time I need to determine which mapper to return. So my solution was having a MapperLocator class that I register with (as above) and return an IDataMapper interface that all of my data mappers implement. Then I can just cast it to type UserMapper if I am dealing with User objects. This however is not so easy when I am trying to determine the type of Data Mapper to return during run time. Since generics have to know what they are at compile time, using AOP and then passing in the type at run time is not an option without using reflection. I am already doing a fair bit of reflection when I am mapping the DTO's to the table, reading attributes and such. Plus my MapperFactory uses reflection to instantiate the proper data mapper. So I am trying to do this without reflection to keep those expensive calls down as much as possible.
I thought the solution could be found in passing around an interface, but I have yet to be able to implement that idea. So then I thought the solution would possibly be in using delegates, but I have no idea how to implement that idea either. So...frankly...I am lost, can you help, please?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会建议几件事。
1）不要过早优化。 如果您需要使用反射来实例化 *Mappers，请使用反射来完成。 看看你因为不这样做而给自己带来的头痛。 如果以后遇到问题，请分析它们以查看是否有更快的方法。
2）我问你的问题是，你为什么要尝试实现自己的 DAL 框架？ 您说 NHibernate 不太适合，但您没有详细说明这一点。 您是否尝试过其他几十个 ORM 中的任何一个？ 你的标准是什么？ 您发布的代码看起来非常像 Linq2Sql 的映射。
Lightspeed 和 SubSonic 都是很棒的轻量级 ORM 包。 Linq2Sql 是一个易于使用的映射器，当然还有 Microsoft 的实体框架，Microsoft 的整个团队都在处理您所描述的问题。
通过查看这些而不是自己实施，您可能会节省大量时间，尤其是维护方面的时间。 我强烈推荐我提到的任何一个。
I will suggest a couple of things.
1) Don't prematurely optimize. If you need to use reflection to instantiate your *Mappers, do it with reflection. Look at the headache you're causing yourself by not doing it that way. If you have problems later, than profile them to see if there's faster ways of doing it.
2) My question to you would be, why are you trying to implement your own DAL framework? You say that NHibernate isn't a good fit, but you don't elaborate on that. Have you tried any of the dozens of other ORM's? What's your criteria? Your posted code looks remarkably like Linq2Sql's mapping.
Lightspeed and SubSonic are both great lightweight ORM packages. Linq2Sql is an easy-to-use mapper, and of course there's Microsoft's Entity Framework, which has a whole team at Microsoft dealing with the problems you're describing.
You might save yourself a lot of time, especially maintenance wise, by looking at these rather than implementing it yourself. I would highly recommend any of those that I mentioned.