Hi, it really depends on what type of applications youre building, and also
the experience level your team has with both OOP and the specific business
domain you need to deal with.
Here is MSFT's application architecture guide (if you search for the term
"object-oriented" in this article it should narrow down to your interest):
http://msdn.microsoft.com/library/de...AppArchCh2.asp
Note: you could apply both approaches you describe. For example, you can
use approach (A) for more generic "helper"-type stuff. But the application
specific DLLs in (B) either reference the compiled classes from (A), or just
are "shared" thru SourceSafe (i assume you would not be making a separate
copy of that class in each project). this isnt very object-oriented... but
one thing to beware of is if your team members insist on a certain approach
"just because".
ie. this type of conversation:
Programmer A: "Hmm, maybe we shouldnt try to impose a stateful
object-oriented model on this set of web services we're trying to build".
Programmer B: "But then it wouldn't be OOP! And I know how to properly
design object models because we did a lot of them in Computer Science
class."
"Jamie Manstream" <Ja************@discussions.microsoft.com> wrote in
message news:B3**********************************@microsof t.com...
There has been some debate at my job as to whether we should use object
oriented or component oriented methodologies when developing our .NET
applications. i.e., A) developing generic, reusable classes that can be
used/reused and inherited from in any number number of discrete
applications
or B) creating completely encapsulated, application-specific DLLs that use
common classes purely by taking an existing class that is stored in
SourceSafe and insering it into a project.
Does the COP method really bear any significant advantages over OOP that
would outweigh its drawbacks? What is Microsoft's recommendation on the
topic?
Thanks!
-Jamie