• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 257
  • Last Modified:

Advice designing .NET system

I need advice on how to structure a full software system solution.
I have some ideas but need to know which technologies should form each component part and how they should interract.
I anticipate using some form of .NET solution but open to suggestions.

There will be a central system with access to many external devices (via com ports) These devices will both send and recieve all the necessary infomaiton to and from the outside world (sensors and actuators etc)
The central system will sit and process the i/o recieved, updating the database with current informaiton and processing the inputs to produce outputs. This will happen 24/7 all the time.
Safety is critical - client would preffer to see this written in c++ but could be persuaded otherwise with good reasoning.
The central system needs to publish all its functionality via a com interface (customer request)

The other side to the system will be a user interface. It is the job of the user interface to get information from what is percieved to be the central system (system + database). I am assuming that the user would not need any info that is not in the database.
The user will be able to initiate certain actions in the central system at the click of a button (eg send a specific message to a specific item of io connected to central system). The user would then be able to view the results of the action on their screen in real time (as monitored with the inputs attatched to central system).
The users interface would essentially have no intelligence, just send and get info depending on button presses.
It is anticipated that it would look and feel like a normal windows program.

There is the possibility for the central system being needed to provide an interface that is web enabled in the future and can also communicate with mobile devices.
This goes hand in hand with possibility needed for dial up access to control server functionality and monitor system (or over IP)

My background is a windows application developer very proficient in Borland Builder needing to switch to visual studio for this job.

QUESTIONS I NEED ANSWERING ??????????????????????????????????????????????
1) Whether the above system sounds reasonable or needs re-ordering
2) What technology would form the user interface ... would it be WinForms ?
3) How would user's client system communicate with central system ? .... would it be SOAP?
4) Should client user interface should be written in c# .... any thoughts?
5) What exactly is the central system classed as ? ... a service ?
        what facilities can it provide and how would it work handling requests whilst running the critical management tasks on the io
6) What are the sub components of the 'central system' should i write its controlling code in c++?
7) Can the 'central system' provide a COM interface .... is this the best type of interface to publish?
8) Should the client use the 'central system' as an intermediary or go straight to the database for info itself ?
9) How should i do the database section - external database eg. SQL Server or use a local db on the 'central sytem itself'?
    such that the 'central system' deals directly with the info without needing to go through another intermediary
10) The system will need to use crystal reports to provide data summaries. Would this run on the server or client
    ..... where would such non functionality critical tasks take place ... server/ client? ideally want client as thin as poss.

Please provide a fully detailed answer explaining each section with options and reasons for your choice

MANY MANY THANKS. will be very interested
  • 4
  • 3
1 Solution
I wrote similar system recently - with only one difference - the 'central system' recieved data from another app, not external devices.So here are my suggestions:

1) As I said - I had similar system already done and running well for few months - so it sounds good :)

2) Windows Forms is really easy to use - you'll save a lot of headache with it.Also - you're familiar with CPP Builder - it'll be even easier.If you're going to write it in CPP - you can use WTL - but it's poorly documented and can cause you a lot of trouble.

3) SOAP is the best form of communication in that case - having in mind that the system will be Web enabled later.

4) Again - C# (or VB.NET in that matter) is good choice for your client app since you got used with Borland's enviroment.

5) Since your system will be running 24/7 - I'd recommend making a console app during your debug/testing phase and later when the time comes for release - service.I think that 3) is the answer to the second part of your question.

6) Maybe just 3 main components - one handling the IO, another taking care for the database and one 'controller' that will take user 'input' (requests from the client) and then re-send them to the IO/database components.

7) I don't think it has to provide COM interface really.

8) If you need really thin client - put the database related code in the server.And here's another idea - you can use MS Application blocks to do this.

9) It depends on how many clients will connect and on what machine will be running your 'central app'.Ideally - if it's possible to have stable MS SQL server on that machine - I'd reccomend to use it.

10) If this isn't critical task - you can leave it in the client.Since your server should be able to respond realtime - this will save you some time.

Also another idea - you can put your IO handling code in an unmanaged DLL and write a wrapper for it in VC++ .NET - so you can call it later from C# for example and write even the 'central app' in C#.Writing the DB stuff in C# is easier and yet safe.

Good luck,
sdom100Author Commented:
Thanks svetlin.
That is just the kind of answer i was looking for.
I would like the leave the post open for a little while to see if any one else has any thoughts.

A couple of questions to clarfy your answer though would really help me....

5) you talk about making a service. Would this be a 'web service' or a 'windows service'... guessing windows.
5b) Instead of a console app, could i easily just add a nice gui form to the app to aid during dev. stages before turning it into a service when completed.. is this win forms again?

6) You talk about creating 3 components. will these be services in their own right or will they just be conceptual componentes existing within one service. If separate then how will they communicate?

7) My customer is very keen on a com interface. In this case would i need to put a com & soap interface or can the winform talk to a single com interface... or can com understand soap ?

8) With regard to "putting database code in the server" do you mean that it would behave as follows: soap request from user for some info. User input component communicates this to Database component that interprets the request and creates specific sql. Database component then runs this on the database getting results set back. set is then passed to User io component and via soap to user?

9) Only likely to really have one client.. maybe a couple more

11) How would the tcpip interface to server work. would the server show a web service?
12) How would the dial up access work? would it just use the soap interface?

SORRY for all the questions but it is essential that i get this absolutely clear in my mind. As you can see the largest area of uncertainty is exactly how the central server system works.
So...on with the show :)

5) yes - sorry about that I really mean windows service

5b) I prefer console - but it depends on you - since this is only for testing.

6) Yes the "components" I'm talking about are just conceptual - different classes (or sets of classes to be more specific) that will exist in the same service.

7) If you need COM & SOAP in your web servce - the first that comes in mind is ATL Web service - there are articles about it on Code Project and in MSDN:
But it will be a real pain I think...

8) That's what I mean - but it will be better if you don't create SQL code in your app - I prefer using stored procedures.

9) So this means you'll have minimal load - and you can have your SQL server on the same machine - if it's stable enough.

10)  you forgot 10 :P

11) if you mean your clients will connect remotely via TCP/IP - there's no problem - they should be able to connect to your service

12) I can't be of much help with dial-up access sorry.Maybe I can't get your question right.
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

sdom100Author Commented:
right, we're nearly there
I promise not to snake on with more and more questions
I just need to straighten my understanding of your answers
5) What is the difference between a web service and a windows service? all the things i have read talk about soap being used with web services.
6) So am i right in thingking that you have a block of code made up of several classes. If it needs to send something over soap then it passes it to my instantiation of a soap class calling the appropriate send method. Likewise if something is recieved by the soap class then i program its event handler to pass the data to my processing class. To do database access, i just use a db component class as you would in other IDE's?
7) How does ATL relate to things - is it not a new, more advanced web server / set of web serving classes - this ties in with question 5.
9) You refer to the machine being stable. I presume by this you mean unliklely to crash. Am i right in thinking that in an ideal world, one has a dedicated db server to try and minimise the likelyhood that it can be crashed by rogue software, thus making the data unavailable?

X1) How would my client side crystal reports access the data would it be able to go help itself (via soap) & db driver?

x2)How will the winforms work over the soap? will it for example be programmed to know it's on it's main form, know it needs info on 20 variables and then ask me for each variable using RPC's, get the info back and populate itself? or does it have data aware components that talk direct to my database server (over soap) - similar to X1 answer maybe

x3)Do you know anything about using RCW's and CCW's apparently these are .Net's wrappers for COM interfacing - again, presumably just modules of code that i can bolt onto my application?

Get these square an i think we're there!
Cheers. S.

5) About Web services services check this link:
The windows service(let's call it reader) will be your connection between the I/O devices and the database.It will read/write data from the external devices and read/write data from the database.The reader may not have "direct" connection with the database - it can use the web service to read/write from DB.

6) That's right - and your database component is called DataSet.

7) About ATL Web Service - check the links I gave you.Just mentioned it - as possible choice for your Web Service.

8) Errm...8) is missing :)

9) Yes - unlikely to crash.And about the dedicated database server - it's really nice to have one - but this is kind of deployment problem.

X1) and X2) Let's get it straight here - if you're using .NET Web serive you'll send/recive your data from/to the server as DataSet.Later you can bind this DataSet to any data-aware component (e.g. grids, combos, etc.).This is also true for Crystal reports.

X3) About COM Interop take a look here:

sdom100Author Commented:
Thankyou for you detailed descriptions good links and patience.
I have now awarded you the points.
Cheers. S.
You're welcome :)
Good luck & happy coding

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now