Re: Is that a good design?
- From: "sloan" <sloan@xxxxxxxxx>
- Date: Tue, 4 Mar 2008 14:15:32 -0500
Since I"ve never mixed them....I've never run into the issues.
I would have been able to reason the first gotcha.
The second one would have been only by experience I think.
But "well put"..this goes into the concrete list of reasons not to do it.
......
That's why I like the multiple resultsets in one datareader method .....
The db connections stay slim and trim.
"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx> wrote in
message news:%23A0vxpYfIHA.4744@xxxxxxxxxxxxxxxxxxxxxxx
We got some code back from a vendor at one time that had each object aware
of its data context. There were two issues with this:
1. The object was coupled to a particular schema (could have been
abstracted with sprocs, I guess, but it was not)
2. When you filled a large report, you slammed the database with dozens of
connections. Ouch!
By separating out the in memory representation of data (state) from its
creator (behavior), you can avoid both of these problems (coupling and
hammering the DB).
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box! |
*************************************************
"sloan" <sloan@xxxxxxxxx> wrote in message
news:%23hnsgyveIHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
I don't like objects that populate themselves either.
I prefer a Controller or Manager
The way I would state it would be
"Seperate the objects...from the code that creates them".
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry
I have a 2.0 version of that entry as well.
"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx> wrote in
message news:Or8A3oveIHA.2000@xxxxxxxxxxxxxxxxxxxxxxx
The factory pattern is very useful whenever you think you might end up
with a change in implementation. This can be due to different clients,
different projects, etc. That part is fine.
I do not see the sense in the User object as it is, however. If you are
creating an object that gets a user, okay, but I would call it something
other than User, lest it be confused with the actual user object. If
what I am seeing here is the actual User object, I am against the
implementation, as the User object should be a data object, with little
or no behavior.
public class User
{
public string UserName;
public string FirstName;
public string LastName;
}
etc.
I would then create some form of collection. Perhaps something like:
public class UserCollection : List<User>
{
}
You can then create a class that creates Users or UserCollections. That
class may be a factory, if there are different types of users, or you
might use a factory to instantiate that class. Both are acceptable
patterns. I would not name this class User, however, as it leads to
potential name clashes.
In general, I do not like objects that fill themselves. While this can
be very useful for lazy loading, you generally end up hammering the
database to fill thousands of objects, which counteracts the one of the
primary reasons for lazy loading (reducing database hits).
Hope this helps.
BTW, while I am not completely sold on their architecture, dofactory.com
has a reference architecture that shows the use of patterns. It does
show how to use the patterns, which is nice, although I would have to
code gen the boilerplate code in their implementation if I were heading
that route (to not do so means you have a more complex architecture for
no reason, IMO).
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box! |
*************************************************
"Robert Scheer" <rbscheer@xxxxxxxxxxx> wrote in message
news:2607cb48-e0f8-432c-9c39-e127890f72dd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi.
I could not find an specific group on patterns, so I am posting
here...
We are trying to develop some patterns to be used on .NET development.
An independent consultant recommend us that we start by using the
Class Factory pattern to help in isolate our code. Our team though, is
complaining that the design is complicated to develop with. I would
like your opinion about this design. Following is a sample of the
recommendation:
Public Interface IUser
Function ReadDetail(ByVal user As String) As String
End Interface
Public Class UserFactory
Private Sub New()
End Sub
Public Shared Function GetInstance() As IUser
Return User.GetUserInstance
End Function
End Class
Friend Class User
Implements IUser
Private Shared _user As User
Public Shared Function GetUserInstance() As User
Try
If _user Is Nothing Then
_user = New User
End If
End Try
Return _user
End Function
Public Function ReadDetail(ByVal user As String) As String
Implements IUser.ReadDetail
'Code goes here
End Function
End Class
On the client side, we have to call the User implementation through
its interface always:
Dim u As IUser = UserFactory.GetInstance
Dim s As String = u.ReadDetail('Robert')
Is it the recommended way to work? Does it allow for inheritance?
Utilities classes should also go this way?
Your opinion is really appreciated!!
Regards,
Robert Scheer
.
- References:
- Re: Is that a good design?
- From: Cowboy \(Gregory A. Beamer\)
- Re: Is that a good design?
- Prev by Date: .NET framework availability stats
- Next by Date: Re: 'is not a valid virtual path' - host header help
- Previous by thread: Re: Is that a good design?
- Next by thread: Re: Is that a good design?
- Index(es):
Relevant Pages
|
