This project has moved and is read-only. For the latest updates, please go here.

How to Handle N-Tier Applications

Oct 18, 2010 at 2:02 PM

I am new to TFS.  We have about 10 applications in our company that are N-Tier designed and subsequently the Data Access Layer (DAL) and Business Logic Layer (BLL) on all of them is exactly the same.  We use Visual Source Safe and just make 10 copies for each application.  We have to manually remember to make any changes to one of these to the others. 

Is there a way in TFS to have the DAL and BLL as a single Team Project but identify that that it is used in conjunction with the 10 applications?

Oct 20, 2010 at 12:11 AM

I would recommend maintaing the shared code (DAL and BL layers) in a separate Team Project. You can then branch the source (or the assemblies) into the other projects that have dependencies on the shared code. You should not make 10 copies of shared code unless you absolutely have to.

The Rangers are writing an article in MSDN magazine on exactly this problem and our recommended solution(s)

Bill Heys
VS ALM Ranger

Oct 20, 2010 at 12:31 AM
Edited Oct 20, 2010 at 12:52 AM

 I strongly, strongly recommend against having seperate team project for each application. Inside of Microsoft, both the Developer Division and the Office division each have 1 team project for their entire portfolio. [Think the Visual Studio and .Net Framework teams live under 1 team project, the Word, Excel, and PowerPoint teams live under 1 Team Project (Office for example).

There's also the huge investment in having multiple process templates/work item definition changes, test plans, test suites, reports, environment VMs (with lab management), email alerts on checkins, code analysis settings, and on and on....Not to mention the fact that there are some nasty nasty bugs in checkin policies if you have more than 1 team project:

I recommned have multiple branches in the same team project in luei of ever using multiple team projects.

Oct 20, 2010 at 12:46 AM
Edited Oct 20, 2010 at 2:51 AM


I guess we will have to agree to disagree on this point. You have made repeated references to the Developer Division and the Office Team. Both these teams are working on completely different programs with very different release schedules and milestones. There is no need to track work items across these two teams as a general rule. This is precisely the case where I recommend separating two very different programs and their teams into separate Team Projects.

Along the same lines, all of the products developed by the office team do have the same release schedule and milestones. These products are highly integrated. This is precisely the scenario where I recommend having even a large complex team working on many features (products) all working in the same Team Project.

There is not a huge issue, in my opinion, around process templates, work item definition changes, etc. These are easily managed for the most part. A benefit of having separate team projects is that the process templates may be the same but can also be quite different.

Test plans, test suites, reports, VMs are all likely to be very different for the office team and the dev div team. These are NOT reasons to force these two teams into the same Team Project.

With respect to the check-in policy bug - this will be fixed, and should not be a controlling factor this decision.

I just have to completely and totally disagree with the perspective that one would never ever use more than one Team Project. That perspective may work for your organization. It would not work for Microsoft internal development ("in lieu of EVER using multiple team projects")

A benefit of Team Project Collections (TPCs) is that they provides for great scalability and reduced back up and recovery times. Each TPC has it's own database, and can be serviced by it's own Data Tier server if necessary. The approach of having all development and release activity taking place on a myriad of branches all within a single Team Project simply won't work for all cases.  I am not opposed to having making this recommendation in some (or many) cases. But it should not be a hard and fast, universal, inviolable rule.

Bill Heys
VS ALM Ranger

Oct 20, 2010 at 12:56 PM

Thanks a ton for the information.  This tells me exactly where I need to go with our source code.  I ultimately ended up putting the source code in just like it was for VSS.  The main reason is because while the application was intended to be n-Tier, it isn't.  Subsequently business rules are spread throughout the application.  So in order to store the code I would have to go through each project and re-write some parts of it.  That leads into my second problem, which is that I don't have the time right now to do all of this.  So my original goal is to get us on TFS and using it for Source Code repository.  I will have time in the future to do the other things.

Oct 20, 2010 at 3:50 PM
Edited Oct 20, 2010 at 3:51 PM

DeHaynes....the quickest and easiest way (should take no more than 1 hr) to get your code into TFS would be to:

1) Create a new Team Project Collection using the TFS Administration Console

2) Crete a new Team Project for storing your source code.[Quick Tip Don't put spaces in the names of your team sharepoint will put  %20 in the URLs which isn't easy to remember...instead of spaces...put periods.....and have a namespace you'd follow...for example [Company.BusinessGroup.Project]

3) Create the default, Main folder, coverted it to a branch and branch it to a  branch named, Development, then checkin your code to the development branch.

If you want to easily add files to TFS download the TFS 2010 September power tools and use the Windows Shell extensions to do the add and checkin directly from windows explorer.

On a side note....Bill we will have to agree to disagree on the multiple team projects...until the bug is fixed...and until the TFS Warehouse doesn't pull workitem fields which results in Schema Conflicts* from multiple team projects/team project collections then my real world time tested guidance would to be very, very careful and have a strong business case for creating another team project.

[In our company we've setup the rule that in order to create a new team project the team has to put up $10,000. The $10,000 is the cost of 1 week of an MCS TFS consultant's time to fix any issues with the configuration of the second Team Project....and hence most teams don't have $10,000 and they end up working under the 1 team project.]

Good luck Dehaynes and if you've got questions post them here and we'll be happy to help.

[Schema Conflicts – In the simple case, when there are two fields in different collections (e.g. Priority) with the same name but a different type (e.g. String vs. Integer) this results in a schema conflict.  That project collection is then blocked from processing warehouse updates and the data in the warehouse & cube becomes stale. see here:]

Oct 20, 2010 at 4:41 PM


Where we disagree... is a blanket statement to never have more than one Team Project (your advice: "I recommned have multiple branches in the same team project in luei(sic) of ever using multiple team projects." emphasis added.)

I think we can agree, especially with respect to the bug / feature you are experiencing with check-in policies is that since you are working in two or more team projects as part of a single program or initiative that perhaps all of this work should be done within a single Team Project. What I have recommended in the past is that you could create a *unifying* team project and branch from each of these separate Team Projects into the *unifying* Team Project. At this point all of your software changes would be done in this new Team Project. It would have (and enforce) its own check-in policies, since you would not be checking-in as part of a single changeset across Team Project boundaries. I prefer this approach, especially when one is starting from having separate Team Projects for each application or solution and where you are making changes that cross application or solution boundaries.

Unless I misunderstand the second issue regarding Work Item conflicts, I think this approach solves that problem as well.

I think this approach provides a reasonable basis for when (and when not) to separate applications (or parts of applications into separate Team Projects. To summarize:

  • Have separate Team Projects - when you have two completely independent initiatives (for example the Microsoft Office Development Team and the Visual Studio Development Team -Dev Div). These two teams are independently managed, work on different applications, have completely independent release schedules and milestones. Having separate Team Projects in this scenario allows independent teams to work with different TFS Process Templates (including customized reports and / or Work Item Type definitions, check-in policies, etc). Each team can establish their own development process (one may be more agile than another, one might be SCRUM - without forcing a single process onto separately managed independent teams.
  • Have a single Team Project - when you have a single developlement initiative (or program) where teams are working on the same release schedule and milestone, even if they are working on separate features or applications (products). Having one Team Project for a single development initiative offers the benefit of having a single TFS Process template with its custom reports, Work Item Type definitions, check-in policies, etc. It is easier for program management to manage an integrated intiative since all work items and reports will be part of a single Team Project.

Bill Heys
VS ALM Ranger