views:

190

answers:

6

I'm planing a larger project,so i'm considering some technology options.

The project will use the 3 tier architecture design. The presentation layer will be ASP.NET but it could be some other technology. This doesn't matter for now.

My questions are:

  1. For the aplication server should i use a windows service or just a normal application ?
  2. What should i use for the communication between the presentation layer and the domain layer ? I wanted to use .NET remoting but i read that remoting is part of WCF. Actually i'm not so familiar with WCF that's why i'm asking. So .NET Remoting or WCF?

I'll appreciate any hint

+2  A: 
  1. Services are the way to go; a user doesn't have to be logged in for them to be running; they are well-equiped for remote administration; they are also better suited for being monitored for health

  2. Remoting can be used via WCF; WCF aggregates many different communication platforms and provides easy-to-leverage configurations for them. Learning WCF would be the better way to go, in my opinion, however if you are versed in Remoting and are certain it covers all your needs then it should be fine too.

STW
+1  A: 

Answering 2)

WCF is a new library that combines different communication mechanism using a single API. Choice of which mechanism (or binding in WCF-speak) depends on what your requirements are.

For performance, you can try out NetTcpBinding, or if you want it to be accessible via HTTP, you can try out BasicHttpBinding. More info on WCF from MSDN.

Adrian Godong
A: 

Actually, your choice of the presentation layer does matter.

If you're doing client-side installations, then using WCF for communication between the domain layer and the client would make sense. However, if you're writing a purely-ASP.NET UI, then having a web app call web services that are likely hosted locally has serious performance implications (messaging and serialization/deserialization overhead).

Thinking about a project I worked on recently, where we needed to support both, we hosted services inside the same app domain as the ASP.NET web interface. The user did most interation through the web UI, and a small client app, which talked to the middle-tier via web services, was launched when richer client-side interaction was required.

ProKiner
Actually the performance cost of a service tier between the UI and the domain is quite negligible. Performance testing that scenario against one that involves no serialisation (assembly references to the domain layer) produces such a low overhead, even on complex architectures, that it is in my opinion, not worth considering. At least, that is my experience.
grenade
+5  A: 

For the application server, right now, I guess Windows services would be your best bet, even though it's more work than it should be. If you don't have to deploy right now, you might want to also have a look at "Dublin" - an add-on to .NET 4.0 that will augment the WAS (Windows Process Activation Server) with management tools and stuff. With this, you might be able to actually host and manage your WCF services in a nice and very powerful way.

As for #2 - I would definitely recommend WCF - it's the platform of choice for communication in distributed systems, and with its configurability and flexibility, it can handle pretty much any task you care to throw at it. From very fast on-machine communication (NetNamedPipeBinding) to handling communication through the Windows Azure ServiceBus - a relay service "in the cloud" - it's that powerful! You can't go wrong with WCF - it can handle all your communications needs, I'd say. Don't waste your time learning deprecated technologies like .NET Remoting or ASMX or WSE web services (just my $0.02 for this discussion).

Marc

marc_s
A: 

If you are asking these kind of questions, then there is still a lot in your project definition you don't know. Not a problem really, since even if you did, most of it would probably change before you finished anyway.

Additionally, whatever technology you pick now will have some significant shortcoming that you weren't prepared for, because it didn't occur to anyone that you would run into some issue.

Don't pick the technology now. Start with something small and deliverable that you understand well, and build it. Develop on top of that in small, managable pieces. Show what you have to your "customer" often and get feedback.

The real trick is architecting it in a way that allows you to easily change direction as new information becomes available. This is where I recommend you spend most of your time - figuring out how to make an extensible architecture, and creating tests to verify everything continues to work as you move forward. As the project grows, the technologies you will need will become much more clear.

+1  A: 

WCF is the only technology to use for communications. Notice that even the .NET Service Bus that is part of Azure uses WCF. As for the other "choices":

There is no other intelligent choice, unless, for some reason, you're stuck using .NET 2.0 or .NET 1.1.

John Saunders