一直很迷惑的有关问题

一直很迷惑的问题
我想很多人都设计过这样的程序结构！
但我这个并发性并不好，希望大家指点一下！
我的初衷是：
业务层改的比较频繁，把它做为一个DLL，灵活一些！

大家有比较好的框架图，给个链接，让我学习一下！自己瞎琢磨，真痛苦！

结构图


[解决办法]

探讨

引用:
运行一个调度程序，它可以开n个线程，分别调用dll
这样，就相当于有n个并发的通道了——相当于n个短连接的交易系统

嗯，谢谢:)
不过在并发时，还是要进行对DLL内的对象进行同步的，这时DLL调用的瓶颈问题就又出现了。我在想把业务对象放在DLL中会不会是一种错误！
ASP.NET好像是将业务代码做成DLL的(对ASP.NET不太熟),人家的并发性怎么搞的，不清楚！

[解决办法]
根据你所展示的结构图，我建议你目前还是不要做接近底层的工作，你那样的设计思路做上层应用都有点勉强。
服务类的系统由于注重响应速度，需要根据特定的目的专门定向设计，其耦合性一般就较高，设计难度也大，设计人员必须具备底层平台的专业知识，且能准确理解业务的特殊性，方能设计出匹配的高效方案。而应用类的系统较注重业务扩展性和灵活性，所以一般要求耦合性较松散，设计也就更人性化。不过虽然人性化程度有了一定提高，也不能完全放弃性能的考量，保证灵活性的同时以合理的体系架构获取基本的性能也是至关重要的。
而我感觉你的整个设计完全按照自己的主观想法，未遵循起码的体系规范，居然出现不停加载同样的DLL情况，简直不能想象，直观上看就是临时在拼凑一个应用，何况是在做服务端。所以你要说如何优化，我无从下手，完全不相关的东西没有改正空间的。
[解决办法]
１.不明白为什么要在COM+对象内用多线程？
２.XML数据有多大？处理XML数据的可能是瓶颈。
３.有时候效率和软件的扩展是相互制约，相互矛盾的。构架的复杂化会影响效率。效率优秀，构架越简单越好。
４.　　“，还要去proxy层把DLL中的对象反序列化，生成SQL，再给DATABROKER，来执行SQL,会不会是这个过程太复杂了 ”：　如果数据多的话，反序列化也是耗费时间的地方。　另个。生成SQL的功能是不是用一个单独的COM+对象来生成。也就是处理数据和根据数据来生成SQL分别对应不同的业务对象。
[解决办法]

探讨

目前来讲，在TObjectBroker初始化时是用
MaxThreads := StrToIntDef(xml.MaxPoolNum, 0);
ThreadGate := CreateSemaphore(nil,5,MaxThreads,PAnsiChar('XXX'));
做的，把请求线程的数量转为5个线程并行，可能是机器性能的原因，一直都不是很理想。
所以我一直把问题认定在DLL访问串行化的问题上了:(

另：
服务器硬件不太可能升级，所以先从软件上找问题！

我只是画了一个简要的图，我在DLL做了业务处理后，还要去proxy层把DLL中的对象反序列化，生成SQL，再给DATABROKER，来执行SQL,会不会是这个过程太复杂了

查看更多 下一篇