如何使用通用类作为服务 [英] How to use Generic Class as Service

问题描述

我的问题可能很愚蠢，但我正在尝试使用我的Generic类。


我有数据访问层，业务逻辑层和表示层（Windows窗体）。每次我必须检索记录列表时，我必须在Bussiness Logic类中调用一个方法（GetList（）），该类在数据访问类中调用SQL查询。每次用户登录时，我都会创建一个新的业务逻辑类实例。因此，每种客户端计算机都有自己的Business Logic类实例。


我在这里尝试实现的是在服务器上一直运行一个Business Logic Class实例，每60秒更新一次最新记录。因此，每当我的表示层从业务类请求数据时，Bussiness Logic类只会将最新记录返回到表示层而不调用数据访问层。有什么方法可以做到吗？


提前谢谢。

Hi,

My question could be silly but this is what I am trying to do here with my Generic class.

I have a Data Access Layer, Business Logic Layer and a presentation Layer(Windows forms). Everytime I have to retrieve a List of records, I have to call a method (GetList()) in Bussiness Logic class which calls SQL query in Data access class. I create a new instance of business Logic class everytime a user LogIn. So in this way each of the client computers have their own instance of Business Logic class.

What Im trying to achieve here is to have a single instance of Business Logic Class running on the server all the time which gets updated with latest records in every 60 seconds. So whenever my presentation layer request data from business class, Bussiness Logic class just return the latest records to presentation layer without calling Data Access layer. Is there any way that I can do it?

Thanks in advance.

推荐答案

你在谈论的是缓存。这可以通过多种方式完成，其中最简单的方法是将缓存直接内置到DAL中。


在最简单的情况下，我可能会使用类似于这个：


BLL会调用数据层，它实际上不再是数据访问层，而是一种缓存机制，用于保存内存中数据的当前视图 - 尽管如此可能是一个很大的内存开销，具体取决于应用程序/数据存储的大小。


数据层又有一个计时器，它将按照可配置的计划从数据库中提取更新 - 如你建议60秒，或者任何合适的东西。


如果我理解你，你的BLL就是客户端机器上应用程序的一部分。这将被配置为访问您的数据缓存而不是您的DAL。


在更复杂的情况下，我可能会变得更复杂并且我的缓存会自动更新，因为仅查询数据如果表已更新。我的表上的触发器可以记录表中最后一次更新数据的时间，我会为我的表上的最后更新保留一个小的时间戳表，每次更新时，该表的时间戳都会更新。当我查询数据时，我的DAL会根据表的时间戳检查缓存数据的时间戳，如果它相同，则返回缓存的数据，如果它不同则更新缓存并返回数据对我来说。这样，第一个用户可以查询新数据。受到惩罚，但是其他人都获得了最新的数据而没有过时的60秒。


您可以很容易地将这些结合起来 - 从您的缓存中拨打一小部分电话向DAL查询是否有任何更新，如果已更新，则获取新数据。你需要对它进行配置，如果你没有得到几乎立即的响应，你就不要等待，而是返回缓存的数据。


这里的技巧是了解哪些力量在起作用以及哪些因素会导致性能问题。客户端服务器应用程序性能问题的两个主要原因是服务器上的磁盘i / o和网络延迟。


除非有必要，否则您可以通过查询数据库中的最少量数据来缓解磁盘i / o，但您显然需要最新数据。最简单的方法是创建一种方法，以了解自上次检查后数据是否已被修改，而无需检查所有数据本身。


您可以屏蔽网络延迟在客户端缓存数据，但这会增加内存要求，或者如果将数据转储到磁盘将产生额外的i / o开销，这可能会影响应用程序的性能。因此，您需要确保这些不会对您的应用程序造成比网络延迟更大的损害。


只是值得深思......


PS使用泛型通常需要反思。如果您没有正确使用反射，使用反射会有很大的性能损失。当然，如果你没有使用反射，你不必担心这个。

What you''re talking about is caching. This can be done a number of ways, the simplest of which is to have the caching built directly in to the DAL.

In the simplest cases, I would probably use some architecture similar to this:

BLL would call the Data Layer, which is no longer actually the data access layer, but a caching mechanism that holds the current view of the data in memory - though, this could potentially be a large memory overhead depending on the size of the application/data store.

The data layer in turn has a timer that will pull updates from the database on a configurable schedule - as you suggest 60 seconds, or whatever is appropriate.

If I understood you rightly, your BLL sits as part of the application on the client machine. This will be configured to access your data cache instead of your DAL.

In more complex cases, I may get a bit more complicated and have my cache auto-update as data is queried only if the table has been updated. A trigger on my table could record the last time data was updated in the table, I''d keep a small table of timestamps for last updates on my tables, every time an update occurs, the timestamp for that table would be updated. When I query for data, my DAL checks the timestamp of the cached data against the timestamp for the table, if it''s the same, it returns the cached data, if it''s different it updates the cache and returns the data to me. This way the first user to query "new data" suffers the penalty, but everyone else gets up-to-date data without it potentially being 60 seconds out of date.

You could combine these fairly easily - have a small call from your cache to the DAL to find out if anything''s updated, if it has been updated, then get the new data. You''d need to configure it such that if you didn''t get an almost immediate response you don''t hang around waiting, but instead return the cached data.

The trick here is to understand what forces are at play and what will cause performance issues. The 2 biggest causes of client server app performance issues are disk i/o on the server and network latency.

You can alleviate the disk i/o by querying the least amount of data from the database unless it''s necessary, but you obviously want up-to-date data. The easiest trick for that is to create a method of knowing if the data has been modified since you last checked, without having to check all the data itself.

You can mask network latency by caching data on the client side, but this will increase either memory requirements or if you''re dumping the data to disk will incur additional i/o overhead which may hinder the performance of your application. So you need to make sure that these aren''t going to have a greater detriment to your application than the network latency would.

Just food for thought...

P.S. Using generics often entails the need for reflection. There are great performance penalties when using reflection if you don''t use it properly. Of course, if you''re not using reflection, you don''t need to worry about this.

我喜欢你的想法，只有在新的变化是表中提供。


我对表格中的每一行都有日期时间戳。因此，在我使用DAL检索数千条记录并将它们更新为带循环的泛型类BLL之前，我将首先在表中检查新记录的存在。但即使在这种情况下，如果我在表中找到一个新行，我将不得不再次更新所有数千条记录。

I like your idea of updating generic class with latest records only if new changes are available in the table.

I do have datetime stamp for each row in the table. So in this way before I retrieve thousands of records using DAL and update them into generic class BLL with loop, I will check the existance of new records first in the table. But even in this case, if I find one new row in the table I will have to update all thousands of records again.

我会用最后一个更新一个迷你表 - 更新的时间戳，每次更新表时，都要更新时间戳。这样你就拥有了一个超轻量级的表，它可以让你确定一个表是否已经更新，而不必查询表中的所有行，检查新的时间戳来计算出来。


如果你的表中有几百万行，那么如果你有任何给定的日期它是否有任何新行可能会很昂贵查询每一行来计算出来。


更好地查询只有几行的表来查明自上次刷新以来是否有任何给定的表已更新，然后只查询那些已更新的表中的行已经从每个更新的表中添加或更新。


因此，如果您只有一个更新的表，您根本不需要查询其他表，只需要更新了一个。这可以节省查询自从我们的缓存上次刷新以来没有任何编辑的一大堆表。

I''d update a mini-table with the last-updated timestamp and each time a table is updated, update the timestamp. This way you''ve got an ultra-lightweight table that will allow you to determine if a table''s been updated without having to query all the rows in the table checking for new timestamps to figure that out.

If your table has a couple of million rows in it, it could get expensive to figure out if it''s got any new rows since any given date if you''ve gotta query every row to figure that out.

Better to query a table with just a few rows to find out if any given table''s been updated since the last refresh, then just query the rows from those updated tables that have been added or updated from each updated table.

So if you''ve only got one updated table, you don''t even need to query the other tables at all, just the updated one. This saves querying a whole bunch of tables that haven''t had any edits since our cache was last refreshed.

这篇关于如何使用通用类作为服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！