|
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.
|
|
|
|
|
my thoughts exactly, thanks for confirming I'm not the only one who's going banana's 
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.)
|
|
|
|
|
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).
|
|
|
|
|
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."
|
|
|
|
|
You've understood my rant  That was idd my issue. I would have done 4 or 5 seperate assemblies as well based on the tasks they perform, especially since most services we will write will perform simple tasks.
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 
Bastard Programmer from Hell
|
|
|
|
|
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 
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.
|
|
|
|
|
That's what he gives as a reason, but IMHO he just wants to put his mark on the team/company.
V.
|
|
|
|
|
Hey!
I'm just doing some research for the next project.
Can you provide me some imformation about Data Fusion? Is there a general approach on how to handle the data and how to combine it to get homogeneous?
regards
Torsten
I never finish anyth...
|
|
|
|
|
|
THAT is what I was searching for - +5 & a big thank you
regards
Torsten
I never finish anyth...
|
|
|
|
|
Hi! Can somebody explain to me why we use a Base interface as a return type in a Factory interface?
Second question in concerned with the code in Main.
I figured out that Factory factory = new ConcreteFactory2() is a reference to the implementation of a ConcreteFactory2 of GetObject() method. What is the next line?
Thanks. I appreciate your help!
abstractfactory
{
class Program
{
static void Main(string[] args)
{
Factory factory = new ConcreteFactory2();
Base obj = factory.GetObject();
obj.DoIt();
}
}
}
interface Factory
{
Base GetObject();
}
class ConcreteFactory1 :Factory
{
public Base GetObject()
{
return new Derived1(); // do we return an instance of derived 1 interface?
}
}
class ConcreteFactory2 : Factory
{
public Base GetObject()
{
return new Derived2();
}
}
interface Base
{
void DoIt();
}
class Derived1 : Base
{
public void DoIt()
{
Console .WriteLine("Derived 1 method");
}
}
class Derived2 : Base
{
public void DoIt()
{
Console.WriteLine("Derived 2 method");
}
}
|
|
|
|
|
Can somebody help me with this?
It's for my colledge presentation and I have to figure it out.
Thanks!
|
|
|
|
|
The abstract factory pattern is explained fairly well here:
http://en.wikipedia.org/wiki/Abstract_factory_pattern[^]
It returns Base as the object type because different factories will return different types of object, but those objects must have something in common.
Imagine a VehicleFactory interface with a method GetVehicle that returns a Vehicle. One type of VehicleFactory might be a PetrolVehicleFactory, that returns vehicles that run on petrol. Another might be an ElectricVehicleFactory that returns electric-powered vehicles. Both of these return type Vehicle, so I can use the factories interchangeably without having to worry about whether it is an ElectricVehicle or a PetrolVehicle that is being handed to me.
VehicleFactory myFactory = new PetrolVehicleFactory();
Vehicle myVehicle = myFactory.GetVehicle();
myVehicle.Start();
myVehicle.DriveOffIntoTheSunset();
I can swap PetrolVehicleFactory for ElectricVehicleFactory, and nothing else in my application needs to be changed:
VehicleFactory myFactory = new ElectricVehicleFactory();
Vehicle myVehicle = myFactory.GetVehicle();
myVehicle.Start();
myVehicle.DriveOffIntoTheSunset();
As long as ElectricVehicle and PetrolVehicle both do what a Vehicle is supposed to do, I don't care what exact type of Vehicle the factory gives me. I just want a Vehicle so that I can drive off into the sunset. It's the factory's responsibility to know what type of Vehicle to make and how to make it.
|
|
|
|
|
A nice, clear and concise explanation; have a 5. 
The best things in life are not things.
|
|
|
|
|
Thank you for your explanation. It's a lot clearer.
Could you just explain the client code?
I mean is Vehicle myVehicle = myFactory.GetVehicle();
a reference to GetVehicle?
Thanks
|
|
|
|
|
The variable myVehicle holds a reference to the Vehicle object returned from the GetVehicle() method.
|
|
|
|
|
Thank you for the answer!
I did well at my presentation! 
|
|
|
|
|
Hi!
I'm new to this forum, so I say hello to everyone!
My question about state diagram is about object states. How are they represented in code?
Are those methods or something else?
And I have another question about operations.
Are operations methods?
I didnt find many pages on google concerning these things so I decided to ask on this forum.
Thank you for your help!
|
|
|
|
|
A state diagram describes the state your program or a sub section of the program is in. So the implementation of a state diagram could be anywhere and everywhere, sorry to be so unspecific.
If your state is specific to one class in the entire application it could be a big switch or if block in the controller for that specific class, think about a car where you have an engine management class responsible for changing gears. The EngineManagement class could contain the switch or if block where each state calls different methods on the GearSystem and Throttle classes.
Also read up on the 'Software Implementations' section on the Finate-State machine, this describes with some examples on how you could implement a state diagram.
|
|
|
|
|
Ok!
Thank you for your help!
|
|
|
|
|
Take a look at this.
If this is the type of state diagrams you are talking about then you can make 1 type of implementation as follows in code:
1) Create a class e.g. MyState.
2) Add a string property State with a private setter and a public getter.
3) Add a public transition method e.g. Transition that takes an argument e.g. Target
4) Let the transition method set property State to Target.
If you instantiate MyState, you have the means to encapsulate a state diagram into an object.
Identify the transitions in other code and let those transitions call Transition of MyState.
In this setup you have a state object that is able to report the state of others.
Sometimes you see MyState as a property on another object. Sometimes MyState is just part of another object.
The later means that an object e.g. MyFoo encapsulates its own state information, which is quite a virtue in OOP.
Example: As a OOP developer you expect that a File object is able to tell if its read-only or closed. You don't want to shop around by other objects to figure that out.
If MyFoo not only encapsulates its state information, but also its state transitions, then MyFoo becomes quite handsome.
In this case the Transit method must implement all possible transitions with their conditions and throw an exceptions (or similar), if it cannot make a transition.
If you let MyFoo make some transitions by it self then it becomes partly autonomous.
If MyFoo becomes 100% autonomous then make the transition method private.
Usually the Transition method is a set of methods e.g. File.Open, File.Close, etc.
Usually the State property is an enum or similar. Some OOPs prefer however the State pattern.
Regards,
Keld
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
