Microsoft Application Architecture Guide
-
You're not the only one finding it confusing. I don't believe they'd use 20 different projects, it'd be mad. Having 20 projects and changing the target framework would be quite a hassle.
-
Since a few weeks my colleague is promoted to teamlead. That fact itself does not bother me, but he does try to impose a certain architectural design (SOA based) and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc... So I did read his indicated chapters (chapter 2 eg) and found most of it common sense really. However he made a sample solution based on his knowledge and creates a new project for each aspect of the application. That means that for one webservice you have a project for the services (svc files), the service contracts (the interfaces), the service implementation (svc.cs files), datacontracts, etc... it ends up in 10 - 20 projects per application. each business layer, dal component, etc should be redone for each application for independency :confused: (the strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell) My problem lies in the fact that if indeed Microsoft supports such an idea (of dividing assemblies) why on Earth do they make it so hard in creating it (you start out by creating a solution with services and adding libraries as you go, but you need to actually MOVE the interfaces and implementation files to different projects. When all this is hooked up in TFS, you know that this could mess up the entire solution and above that you need to reference your projects all over the place to make it work. Personally I have a serious doubt this is a good way of working. If it really should be this way, why doesn't Visual Studio have this option or makes it so difficult to implement? I'm for dividing logic and creating n-Tier applications, but personally I wouldn't start dividing a service project into servicecontracts, datacontracts, implementation, services assemblies. Am I missing a point here, because this is pretty confusing. :sigh: many thanks.
V.
V. wrote:
Since a few weeks my colleague is promoted to teamlead. That fact itself does not bother me, but he does try to impose a certain architectural design (SOA based) and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc...
I am curious why a "team lead" is acting as an architect and/or boss. As a development group if you want to create guidelines (code, architecture, process, whatever and etc.) then the development team, as a group, creates them, reviews them and approves them.
V. wrote:
My problem lies in the fact that if indeed Microsoft supports such an idea (of dividing assemblies) why on Earth do they make it so hard in creating it (you start out by creating a solution with services and adding libraries as you go, but you need to actually MOVE the interfaces and implementation files to different projects. When all this is hooked up in TFS, you know that this could mess up the entire solution and above that you need to reference your projects all over the place to make it work. Personally I have a serious doubt this is a good way of working. If it really should be this way, why doesn't Visual Studio have this option or makes it so difficult to implement?
Your description doesn't make it clear what you find to be difficult. If you have an existing application(s) and you need to completely restructure them to some other form then it is going to require work. And there isn't anyway to automate that. On the other hand if you are creating new applications then at least for me working with different projects (and even solutions) and then combining them to create the final application is the only way I work (and in languages other than .Net as well.) Trivial apps can exist in a single space but with large apps I would expect tens of different divisions. Combining them is only relevant to the final app and for direct dependencies in the different parts. Understanding small parts is easier than understanding one large mass. I would suppose it also tends to keep the boundary layers more independent. (Note however that I am not commenting on the MS methodology itself.)
-
V. wrote:
Since a few weeks my colleague is promoted to teamlead. That fact itself does not bother me, but he does try to impose a certain architectural design (SOA based) and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc...
I am curious why a "team lead" is acting as an architect and/or boss. As a development group if you want to create guidelines (code, architecture, process, whatever and etc.) then the development team, as a group, creates them, reviews them and approves them.
V. wrote:
My problem lies in the fact that if indeed Microsoft supports such an idea (of dividing assemblies) why on Earth do they make it so hard in creating it (you start out by creating a solution with services and adding libraries as you go, but you need to actually MOVE the interfaces and implementation files to different projects. When all this is hooked up in TFS, you know that this could mess up the entire solution and above that you need to reference your projects all over the place to make it work. Personally I have a serious doubt this is a good way of working. If it really should be this way, why doesn't Visual Studio have this option or makes it so difficult to implement?
Your description doesn't make it clear what you find to be difficult. If you have an existing application(s) and you need to completely restructure them to some other form then it is going to require work. And there isn't anyway to automate that. On the other hand if you are creating new applications then at least for me working with different projects (and even solutions) and then combining them to create the final application is the only way I work (and in languages other than .Net as well.) Trivial apps can exist in a single space but with large apps I would expect tens of different divisions. Combining them is only relevant to the final app and for direct dependencies in the different parts. Understanding small parts is easier than understanding one large mass. I would suppose it also tends to keep the boundary layers more independent. (Note however that I am not commenting on the MS methodology itself.)
jschell wrote:
I am curious why a "team lead" is acting as an architect and/or boss.
That would be his job.
jschell wrote:
As a development group if you want to create guidelines (code, architecture, process, whatever and etc.) then the development team, as a group, creates them, reviews them and approves them.
Nope, won't work; too many cooks: you'll never get agreement until someone says 'stop arguing and just get on with it' or casts the deciding vote. When I start a new project I dictate how it will happen, standards, etc., and that is how it goes: don't have time to dick about debating where comments should go or whether or not we use use regions or separate the project out into this bit and that bit. If someone comes to me with a good idea that can be easily retrofitted then I'm all for it otherwise won't happen till the next project some fool puts me in charge of. I do, however, agree with much of your final paragraph though I will (usually) have a single solution broken down into logical parts with sub-solutions/projects as needs dictate.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
jschell wrote:
I am curious why a "team lead" is acting as an architect and/or boss.
That would be his job.
jschell wrote:
As a development group if you want to create guidelines (code, architecture, process, whatever and etc.) then the development team, as a group, creates them, reviews them and approves them.
Nope, won't work; too many cooks: you'll never get agreement until someone says 'stop arguing and just get on with it' or casts the deciding vote. When I start a new project I dictate how it will happen, standards, etc., and that is how it goes: don't have time to dick about debating where comments should go or whether or not we use use regions or separate the project out into this bit and that bit. If someone comes to me with a good idea that can be easily retrofitted then I'm all for it otherwise won't happen till the next project some fool puts me in charge of. I do, however, agree with much of your final paragraph though I will (usually) have a single solution broken down into logical parts with sub-solutions/projects as needs dictate.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
digital man wrote:
That would be his job.
At the places where I have worked where the position "team lead" existed there were also other roles. Such as "manager", "architect" and even "VP", etc. Smaller shops might choose to call a manager a "team lead" but that wouldn't change the definition in my mind. To me a "team lead" provides technical direction. They are not in charge of personal management nor are they the final arbitrator. A "manager" on the other hand is.
digital man wrote:
Nope, won't work; too many cooks:
First let me clarify that my comments were made in the context of moving towards a formal process control system. From that I have no idea what you mean. It certainly has worked for me in a number of different companies. Matter of fact I believe there is a tenet of process control and perhaps even studies that back it up that process control will not work unless the participants are allowed to contribute to and approve the process. Without that then the point of process control will fail because it will end up as a paper pushing exercise.
digital man wrote:
When I start a new project I dictate how it will happen, standards, etc., and that is how it goes: don't have time to dick about debating where comments should go or whether or not we use use regions or separate the project out into this bit and that bit.
Not sure what your point is. Coding guidelines, which is what most of your comments seem to indicate you are referring to, is a trivial and ineffectual piece of most process control. It is often implemented because it is easy yet will have zero impact on actual productivity for an organization that does not have comprehensive process control. And process control will not succeed at the project level. And that is backed by at least one study. It demonstrated that process control would not achieve success (something measurable) unless it was pushed down from the senior level (VP and higher).
-
Since a few weeks my colleague is promoted to teamlead. That fact itself does not bother me, but he does try to impose a certain architectural design (SOA based) and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc... So I did read his indicated chapters (chapter 2 eg) and found most of it common sense really. However he made a sample solution based on his knowledge and creates a new project for each aspect of the application. That means that for one webservice you have a project for the services (svc files), the service contracts (the interfaces), the service implementation (svc.cs files), datacontracts, etc... it ends up in 10 - 20 projects per application. each business layer, dal component, etc should be redone for each application for independency :confused: (the strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell) My problem lies in the fact that if indeed Microsoft supports such an idea (of dividing assemblies) why on Earth do they make it so hard in creating it (you start out by creating a solution with services and adding libraries as you go, but you need to actually MOVE the interfaces and implementation files to different projects. When all this is hooked up in TFS, you know that this could mess up the entire solution and above that you need to reference your projects all over the place to make it work. Personally I have a serious doubt this is a good way of working. If it really should be this way, why doesn't Visual Studio have this option or makes it so difficult to implement? I'm for dividing logic and creating n-Tier applications, but personally I wouldn't start dividing a service project into servicecontracts, datacontracts, implementation, services assemblies. Am I missing a point here, because this is pretty confusing. :sigh: many thanks.
V.
I've worked on a Service project that had 14 projects. It worked well and the separation made sense. Definitely separating the functionality from the service itself makes a lot of sense. Why would you put yourself through the pain of testing a service if you could avoid it. Just like everything, it needs to be considered in context. A simple service probably only needs 4 or 5 assemblies. A large, complex service could easily require 20 or more projects. To demand the same architecture across the board however would appear needless. If I was to build even a small service I would have at least 4 projects. Service project (wrapper to the Business logic) Winforms test project (To test business logic and behaviour) Business logic project Deployment project Personally I wouldn't have a problem but it sounds like your colleague may be getting a bit over-excited. Best he sticks to changing the colour of his waste paper basket for the first short while and get the team onside ;)
"You get that on the big jobs."
-
I've worked on a Service project that had 14 projects. It worked well and the separation made sense. Definitely separating the functionality from the service itself makes a lot of sense. Why would you put yourself through the pain of testing a service if you could avoid it. Just like everything, it needs to be considered in context. A simple service probably only needs 4 or 5 assemblies. A large, complex service could easily require 20 or more projects. To demand the same architecture across the board however would appear needless. If I was to build even a small service I would have at least 4 projects. Service project (wrapper to the Business logic) Winforms test project (To test business logic and behaviour) Business logic project Deployment project Personally I wouldn't have a problem but it sounds like your colleague may be getting a bit over-excited. Best he sticks to changing the colour of his waste paper basket for the first short while and get the team onside ;)
"You get that on the big jobs."
-
Since a few weeks my colleague is promoted to teamlead. That fact itself does not bother me, but he does try to impose a certain architectural design (SOA based) and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc... So I did read his indicated chapters (chapter 2 eg) and found most of it common sense really. However he made a sample solution based on his knowledge and creates a new project for each aspect of the application. That means that for one webservice you have a project for the services (svc files), the service contracts (the interfaces), the service implementation (svc.cs files), datacontracts, etc... it ends up in 10 - 20 projects per application. each business layer, dal component, etc should be redone for each application for independency :confused: (the strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell) My problem lies in the fact that if indeed Microsoft supports such an idea (of dividing assemblies) why on Earth do they make it so hard in creating it (you start out by creating a solution with services and adding libraries as you go, but you need to actually MOVE the interfaces and implementation files to different projects. When all this is hooked up in TFS, you know that this could mess up the entire solution and above that you need to reference your projects all over the place to make it work. Personally I have a serious doubt this is a good way of working. If it really should be this way, why doesn't Visual Studio have this option or makes it so difficult to implement? I'm for dividing logic and creating n-Tier applications, but personally I wouldn't start dividing a service project into servicecontracts, datacontracts, implementation, services assemblies. Am I missing a point here, because this is pretty confusing. :sigh: many thanks.
V.
V. wrote:
and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc...
I do like to re-use a lot of their work, patterns and idea's from MSDN.
V. wrote:
and found most of it common sense really.
Sounds good.
V. wrote:
creates a new project for each aspect of the application
What would common sense do?
V. wrote:
strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell)
..but it it the Microsoft way, exactly with that title as a claim. From MSDN; Simplifying Deployment and Solving DLL Hell with the .NET Framework[^] It's kinda cool to list different versions of a "save"-plugin that you found and have the user select the version to save with :suss:
Bastard Programmer from Hell :suss:
-
V. wrote:
and motivates his decisions by saying it is the Microsoft way and read book X or Y, etc...
I do like to re-use a lot of their work, patterns and idea's from MSDN.
V. wrote:
and found most of it common sense really.
Sounds good.
V. wrote:
creates a new project for each aspect of the application
What would common sense do?
V. wrote:
strange thing is, when I mentioned the GAC, a Microsoft way of working, the response was that that wasn't an option and didn't solve dll hell)
..but it it the Microsoft way, exactly with that title as a claim. From MSDN; Simplifying Deployment and Solving DLL Hell with the .NET Framework[^] It's kinda cool to list different versions of a "save"-plugin that you found and have the user select the version to save with :suss:
Bastard Programmer from Hell :suss:
Eddy Vluggen wrote:
What would common sense do?
lol, for me common sense would be to avoid complicating things unnecessary. His idea is to work with "enterprise" applications. Performance is not his main concern (read, not important). I can agree on an "enterprise" application if it is a large one, but for a simple module (most of them are) I'm not seeing the added value. Looks to me like we're using a bazooka to kill the mosquito ;P
V.
-
Eddy Vluggen wrote:
What would common sense do?
lol, for me common sense would be to avoid complicating things unnecessary. His idea is to work with "enterprise" applications. Performance is not his main concern (read, not important). I can agree on an "enterprise" application if it is a large one, but for a simple module (most of them are) I'm not seeing the added value. Looks to me like we're using a bazooka to kill the mosquito ;P
V.
-
Or wanting everything to be done the same way, every time, whether it's a large or small project. I guess that has its points.
It always itches for the first week or so. My Mu[sic] My Films My Windows Programs, etc.