...
I posted a thread in another group. I could not get
satisfactory feedback. I would like to try if anybody
in this group can help me out.
I don't know what you mean by "satisfactory feedback", but I think that the
answers you got in microsoft.public.dotnet.framework.adonet,
microsoft.public.dotnet.framework.aspnet and
microsoft.public.dotnet.framework.windowsforms pretty much covers the most.
My plan was, to develop components at server side
(something like EJBs).
..NET lacks anything remotely close to the concept of EJBs.
However, ADO.NET have other advantages that can make that a better choice
over e.g. JDBC.
For data entry and operation application functions,
I can use C#.Net.
You can use pretty much anything for data entry and operation application
functions.
For reporting and enquiry functions, I can use ASP.Net.
You could use ASP.NET for data entry as well.
And you can also pretty much anything for data entry and operation
application functions as well.
You may aware that these two packages
have a lot in common.
You don't say...
Under J2EE environment, I know how to it
through EJBs the 'shared components'.
Under .Net, what should I do?
Here you've got a multitude of possibilities, but...
Can I have the environment of C#.Net + ASP.Net
+ Unix server (as database server as well as
deployment server)?
At the moment the use of .NET on a Unix server is pretty risky.
It seems that the only choice I have is to use VB or
Delphi and ODBC. If that is the case, I would have two
piles of shit in my hands: 1) J2EE; 2) .Net.
That's *not* the case, but your conclusion is interesting, puzzling and
seems a bit confused. At least it's confusing me!
If the case is that your customer (or whatever) demands a Unix server,
certainly the first choice would *not* be to look into "VB or Delphi and
ODBC". Those are foremost used on Windows, and if you have the possibility
to run everything on a Windows server anyway, I would rather recommend some
..NET-solution, such as C# + ADO.NET + ASP.NET.
If you can't do without the Unix server, you still have a lot of choices,
but then you must look further into what the requirements really are. Just
to give a few examples (based on the demand of a Unix server):
- The complete platform independency:
Do *everything* in Java! (J2EE, EJB, servlets, etc)
- The n-tier solution:
a) Wrap the Entity beans into Webservices (in Java),
which can be called from C#-clients
b) Use the Unix server as a database server only,
and use ADO.NET and ASP.NET on a separate
Windows server for the access from clients
Those were just a few examples, but you have to look further into what the
requirements *really* are.
So, if you question is if .NET can work *on* Unix, the answer can only be
"to some extent, but not recommended (yet) for live business purposes".
If your question rather is if .NET can be used in *conjunction* with a Unix
server, the answer will be a definite "yes, but with that server only as a
backend for some specific purpose", and to be precice, you must define the
overall system architecture to be used.
Finally, the question should rather be why the customer demands a Unix
server in the first place? Why doesn't he/she demand some specific
functionality of the system instead, and lets the developers decide on what
solutions that can make the best choices?
my 2c
// Bjorn A
P.S. There's an obvious reason why Microsoft at this moment doesn't develop
..NET for Unix or Linux. They simply don't wan't to support any OS that is
competing with their own, Windows...
However, if you can wait a couple of years, something might come up in the
new collaboration between Microsoft and Sun.