DCSIMG
How to structure .NET Solutions and Components - Podcast - Udi Dahan - The Software Simplist

Udi Dahan - The Software Simplist

For more information, visit www.UdiDahan.com - my main blog.

How to structure .NET Solutions and Components - Podcast

Hello World, and welcome to “Ask Udi”, the podcast where listeners get their questions on IT Architecture answered. This is your host, Udi Dahan, bringing you the cold, hard facts you need to make decisions about SOA, Web Services, Domain Driven Design, Object Relational Mapping, Smart Clients – well, you get the picture. If it’s IT, it’s fair game. I am “The Software Simplist”, helping you Keep It Simple.

This week’s question comes from Mike who asks:

Hi Udi,

I was wondering if you could help me out or point me in the right direction. I’ve been programming on the .Net framework for several years now and want to move towards an architecture role. Additionally, I have been reading up on WCF and related .Net 3.0 technologies, but have more questions than answers.

1. Do you have guidelines/best-practices for how to structure a .Net solution and related assemblies? Also, guidelines as to how to factor the various namespaces and what goes where would be helpful.

2. How should components be factored, i.e. one component to an assembly or multiple components to an assembly? I’ve read several different articles that go back and forth, but never really got a straight answer.

3. How do components relate to services from an SOA perspective?

4. Does application scope/size impact the decision to use SOA? And,

5. Do you have any resources that I could use to learn more about SOA and .Net?

I appreciate the help and any answers that you can provide.

Mike

Get it here.

Additional References

Dependency Injection Tools:

Podcasts:

Want more? Go to the “Ask Udi” archives.

Comments

No Comments

Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: