.net development code structure -Controllers, Services, Repositories & Contexts

As a new developer I'm getting thoroughly confused by naming and structural conventions for developing c# code using best practice.

I appreciate it's perhaps applicable to each domain I am developing for but I've seen the code of many different open source projects and there seems to be a common theme. The successful projects have well thought out structure for maintenance and extensibility.

The terms context, service, repository and controllers are used often and I wondered if these are open to interpretation or is there a consensus or convention on what, where or how these get used.

In an e-commerce platform I've seen there are order services, order contexts, customer repositories and product controllers for example. What should they do based on these names? Does a cont开发者_JAVA技巧roller do something different to a service? When should you use a context? Is there a convention for namespaces? It's mind boggling when you try and push from a spoon fed newbie developer and try to move on.

What software/tools should I really be looking at to develop quality code? Unit Testing, Continous Integration, Resharper, Mocking tools, DOI Containers, nHibernate.

I'm not really aware of blogs/books that will help me push on from being a proficient web developer into someone who can develop extensible, quality and testable code. There are big gaps in authors assumptions. You are either a newbie or a software architect.

I want to push from being a junior developer with a long term aim of being a software architect. I realise it's all about patterns and practices but where are the training materials? I work on my own so don't have the opportunity of learning from others.

Thanks

I don't think there's a perfect solution for your answer. I confused myself too. But with my experiences in the work and school, I made my own rules. Maybe will give you a clue about what you asked.

I assume that you already known about MVC design pattern. Where Model is about to handle your business's logic and database thing. View is what you want to be seen in the screen. And the controller is to response users' request and decide which view and model should be loaded.

I usually organized my Model by creating some folder(namespace) to achieve it. Here's my Model:

• Repository: will only do query, insert, update and delete a single table(Interface and Implements).
• Services: the combination of the tables based on Repository, do login and logout, and some others that not related to database access.
• Classes: are the declared object.
• Utils: static functions redirect from Repository and can be called by View.

Maybe you can share yours!!

For unit Testing there is NUnit. For Continuous Integration there is CruiseControl.net For mocking there is Moq, or RhinoMocks, personally I find Moq simpler and easier to learn. For DI there is Ninject, and Structuremap and some others, I prefer StructureMap. These are the ones I have used and usually there is more than one option.

If you want a good book that will get you into ASP.NET MVC, common design patterns like Repository pattern, and into developing testable code I recommend Pro ASP.NET MVC 2

As for the naming conventions you are talking about, this are common Domain Driven Design conventions, a lot of people are using or partially using DDD in .NET, you can get more info here.