N-Tier, is the right choice?

[Adine]

Hi,

I need to develop a program to control electronic instruments. We have so
many different instruments but we can group them. Each group has some common
functions. When user choose an instrument, the other instruments may not be
needed at all. So I was thinking if I want to write one executable file and
put all instruments functions in it, I will have a huge file and user just
needs 2% of that. So I thought that could be better to have an executable
file for each instrument. But we need a form to choose them, plus they are
some common functions in a group or there are some functions to link two
different instruments. So each executable file should be individual but not
completely (not in separate solution). Now how should I design it? Should I
use N-Tier solution?

Thanks

 

[The Crow]

place all common functionalty in a seperate dll, place shared by some
instruments's functionalty as seperate as you can in multiple dll files. and
at least, place instrument specific functionality in its own dll. then use
them like plug-in's. tiered architecture would be good idea.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

You are confusing two things, the logical design ( classes,struct , etc )
and physical ( .dll , .exe )
IMO at this point you should concentrate in the first, how to implement the
classes, you said that you can group them , maybe this can be represented
with one abstract base class that implement (or define) the common
functions.

You have to define an abstract instrument from where all the groups derive
from. This would allow you to create a collection of instruments. If as it
seems from your post an user can select what instrument it can choose from
then you could for example declare all of them in an assembly, then you
could using reflection get all the classes that implement a giving interface
(IInstrument).


Depending of how big your code is you could put them in a single dll. If
not possible remember to declare the shared declarations ( Interfaces, etc)
in a single dll and make all the other dlls reference this common one.

Take a look at http://www.yoda.arachsys.com/csharp/plugin.html

cheers,

 

[Adine]

Thanks for your help. Now I have a better idea how to design the program. As
you mentioned, I confused. I'm newbie in OOP I will go and study more
on your answers and I may back to you guys with more questions

Thanks again

 

[Kevin Spencer]

Should I use N-Tier solution?

No. You don't yet know what an N-Tier solution is yet. If you did, you would
not need to ask. Pop phrases may impress your peers, but they don't pay the
bills, get you a raise, or improve your lot in life. Knowing what they mean
is much more valuable. I would suggest some earnest study into the subject,
and then you will know what to do and how to do it.

Here's a good place to start:

http://search.microsoft.com/search/results.aspx?qu=N-Tier+architecture&View=msdn&st=b&c=4&s=1&swc=4

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Bob Powell [MVP]]

It sounds to me as though you need a plugin solution. N-tier refers to
distributed applications where the user-interface, business-logic, workflow
and database layers are disconnected. You have a buzzword overload.

For instruments that have common functions, create a base class that caters
for the functions. For more specialized cases, create a DLL that contains
classes based on the common base-class DLL.

You can create plug-in solutions easily with .NET. I guess what you really
need is architecture advice.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Bob Grommes]

Keep in mind that the size of an assembly (whether it's an EXE or a DLL)
does not equate to runtime memory consumption, in that each *method* is
JIT compiled the first time it's executed. If you have 1500 methods and
only use 40 of them, then only 40 methods get JITted and reside in memory.

You don't need to be overly concerned with the size of your assemblies.
Organize your solution logically in projects and the assemblies will
pretty much take care of themselves. I would have the application in
one project, the common routines used by various instruments in another,
and then a specific project for each instrument. The end result will be
that the application will be an EXE, and each instrument will have its
own DLL and the app will use a shared DLL with shared classes and
utility methods plus the DLL for the instrument it's working with. I
would do this not out of a concern for assembly size, but just because
it's a logical way to organize things and increases the likelihood of
code reuse in other solutions.

--Bob

 

[The Crow]

+ updating base functionality, or upgrading, will be more easy.