Design and Architecture

There are many areas that you need to look at. Are your queries running against indexed values? Are you bulk loading too much data? Should you be lazy loading? What can you cache? To be honest, whoever designed this system should have thought about these issues right at the start - it's going to cost a lot more to fix the system now that it's live than it would have cost at the design stage. BTW - 300MB isn't very big, you need to sort this out now before you get to terabytes. "WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes. My blog | My articles | MoXAML PowerToys | Onyx

Hi! erwin - because, its the best. -------------------------------------------------- custom logo design

I know you included the word "Design and Architecture" in your request but this is just another request for codz and as such has been downvoted and ignored. However it is a slow Friday and I'm bored so... When do you expect this process to run? Assuming on first startup Your classes should reflect your test cases this can only be designed with the knowledge of the test. The app should run the test processes before any other process The tests should report and persist the results so subsequent starts do not repeat the tests Never underestimate the power of human stupidity RAH

Hi ! I've just visited this forum. Happy to get acquainted with you. Thanks. __________________ Watch Splice Online Free

You are right ... there is no possibility of client being web or silverlight. I don't understand, what you mean by cost ... you mean cost of time needed for implementation? As I mentioned there is only one table (0 - few hundred records) that is critical for real-time data. This table holds items being currently processed and changes rather often and must be refreshed as soon the change happens, because operator actions depend on current data. I intend to inform the clients via dedicated publish/subscribe WCF service. The core service would publish events and clients would subscribe to events. So e.g. when data is changed due to processing, core service would raise an event and event args would hold dataset instance with data changes, the clients would then merge received changes to own dataset instance. Here lies my main concern - is dataset too big data structure to be efficient enough - I'm also considering custom "light-weight" business entities, but it is easier for me to use dataset infrastructure. I actually didn't give a lot of thought to concurrency - all data tables have time-stamp column and I suppose core service would grant or deny data update based on that value. I also haven't use dataset merging ... I have done some reading about it and it seems the main problem lies in auto-incremented columns - there is great possibility for duplicate or missing data if used improperly. Anyway, thanks for your time, it's been helpful, specially for pointing out some issues that I didn't yet think of and might arise. Tine

I'm a great believer in roll your own, mainly because I'm an old fart who has all the tools/framework already built. However one of our teams recently did some work in both EL and nHibernate. Its was concluded that the only reason for a framework was to maintain database agnostic code. There was approx a 50% speed penalty when moving from stored procedure to framework (we do batch processing rather than transactional systems). As we have strong SQL skills (you don't get a job if you can code TSQL) we have retained the procedures and a fairly simple framework where each table is represented by a generated class (our own classbuilder app). Never underestimate the power of human stupidity RAH

Hi, Ted... Not sure what is meant by OO in this context. Looks more like a UI design issue. I think I'd ditch the textbox/combobox combination and go with RadioButtons, NumericUpDown and Labels. Wish I could insert an image here, but, it would look like this: > Three RadioButtons stacked in a column. > The Text for the top radio button would be "Cash". > The Text properties for the other two RadioButtons would be blank. > The second RadioButton would be followed by a NumericUpDown control with a Minimum of 1 and Maximum of 99. To the right of this NumericUpDown control would be a Label that displays "days after delivery". > The third RadioButton would be followed by another NumericUpDown control with a Minimum of 1 and a Maximum of 12. To the right of this NumericUpDown control would be a label that displays "months after delivery". The user would select a radio button and, if needed, either enter or select the number of days/months. Based on which radio button is selected, the program will know how to react. Hope that makes sense. A screen capture would be better. If you want one, I can email it to you. George

Ahhh. Thank you for your 2ct's. Its great hearing different ideas as I was thinking about it from a different angle.

Personally, depending upon the type of game, Multi-tier architecture may not always fit well just due to the potential performance issues, unless you are talking tiers that all reside on the same system, and then it could even induce issues. Remember, N-Tier is typically used to solve business level solutions where you can perhaps tolerate a bit of lag or delay between layers. In systems where people are going to expect near real-time performance N-Tier may NOT be the way to go. Now, using for parts of the game like authentication, score keeping, maybe chat areas within the game, sure, but as far as actual game play (again, depending on the actual requirements of the game) N-Tier may not be the best choice. LinkedIn[^] | Blog[^] | Twitter[^]

Thank you :)

Hi Jack, here is my basic approach: - write initial documentation (basic design and information flow) - write unit tests (at least a few, because you will need them after next step) - refactor (there are many books about it, see also code refactoring[^]) - test extensively that functionality is still working and you haven't broken anything - complete your documentation (to the extend needed) Now you are ready to redesign and extend where needed. Btw, in some cases it is easier to just rewrite the whole mess from scratch, in any case keep the outer interfaces in the first refactoring round so you don't end up rewriting the whole application. Hope this helps! :) /M Chat in Europe :java: Now with 24% more Twitter

RajeevBhatt wrote: Winforms Vs ASP.NET Winforms does not really qualify as thin client, and will require setup and deployment. This increases the cost of operations. RajeevBhatt wrote: Communication, It depends on your network architecture. If you have a homogenous corporate network, with well configured internal firewalls, go for the framework that gives you the most functionality, like WCF. If on the other hand, you will have to deal with different authentication mechanisms or domains, or with firewalls that only allow certain types of communication, you may have to kick down to a lower level of in-built functionality. RajeevBhatt wrote: Data persistence, Again, it depends: you may use a persistence framework like the entity framework, but if your data is not well suited to relational operations (and is large enough), you may have to deviate a lot from standard mappings, in order to optimise performance, to the point where a persistence framework becomes more a burden than an asset. RajeevBhatt wrote: Performance, Architecting for performance will again depend on the functionality of the app. Will you be able to scale on different servers, or are the operations single-threaded by nature? Will you be able partition your database, or will the queries by their nature prohibit partitioning. As you see there is no 'right' architecture. Architecture depends on what you want to do. It's the same with building architecture: If you want a lighthouse, you'll probably design a tower-like structure close by the sea. It will probably be unusable as a soccer stadium though :-)

This may help you http://www.codeproject.com/Articles/79832/Programming-for-N-Tier-layered-architecture.aspx[^] Its about a layered based design so it may be able to help you :-D

Imperfect C++: Practical Solutions for Real-Life Programming[^] could give some tips on memory management. Update: Oops you said C (Not C++), ah well it's a good book. :-O Webchat in Europe :java: Now with 26% more Twitter

www.code-magazine.com Everything makes sense in someone's mind