Abstraction question

  • Thread starter Thread starter Eric Cathell
  • Start date Start date
E

Eric Cathell

I am using dOOdads as my persistence layer.

I have a business object Person that sits in a Project called DOMAIN
I have 2 dOOdads in a project called BLL.

one is _Person and is declared MustInherit
the other is Person and is my concrete class.

My main goal of BLL.Person is to protect custom methods and properties
against regeneration.

DOMAIN.Person is my actual object for all my Rules and such for person.

so in DOMAIN.Person I have code like this

Private _person As BLL.Person

Public Function getPersonByID(ByVal id As Integer) As BLL.Person

If _person.LoadByPrimaryKey(id) = False Then
Throw New Person.InvalidPersonException
End If
Return _person

End Function

The problem is I am getting the following error in my compiler:
Construct makes an indirect reference to project 'WavelengthIS.CMR.BLL',
which contains 'WavelengthIS.CMR.BLL.Person'. Add a project reference to
'WavelengthIS.CMR.BLL' to your project. C:\Documents and
Settings\ecathell\My Documents\Visual Studio
2005\Projects\WavelengthIS\CMR-Versioned\NunitTESTS\Form1.Designer.vb

Now I am sure there is some design way around this. I am just delving into
some of the more complex patterns and the thought is at the tip of my brain.
I am missing an interface somewhere( probably in my function) as IPerson.

but if I do an interface on IPerson...how do I maintain the bll._person to
bll.Person inheritence?

Hopefully what I am asking makes some kind of sense.
 
Sept. 6, 2006

I don't quite understand the question completely, but if you are wanting
your code to work and explain why the error is occuring.... it may be
because you have declared a variable "_person" which is the exact same name
as the MustInherit class _Person (I don't believe class names & variables
are case-insensitive in C#... like if you have Button1 object on your
windows form, you can't declare "button1" in your code.)

So anyway, try changing your _person variable to something else like
"persontoreturn" or something.

Hope this helps and is what you were asking for!
--
Joseph Bittman
Microsoft Certified Solution Developer
Microsoft Most Valuable Professional -- DPM

Web Site/Blog: http://CactiDevelopers.ResDev.Net/
 
I got that issue solved but lets carry on with this conversation. I think I
am confused about abstraction.


we have a class

Namespace myCompany.MyProgram.DAL
Protected MustInherit Class _Person

members
properties
methods

end Class
end Namespace

Now This class is kept in a separate project so that DAL will compile into
its own DLL.

next we have this

imports myCompany.MyProgram.DAL

Namespace myCompany.MyProgram.BLL
Public Class Person
Inherits _Person

members
properties
methods

end Class
end Namespace

Once again this is kept in a separate project so that BLL will compile into
its own DLL.

Now if I want to create a facade layer(because person has several dependent
objects that the end user really doesnt need to know about.

So now I have

Namespace myCompany.MyProgram.Domain
Public class PersonFacade

private _p as Person

public sub new()
_p=new Person
end sub
public sub SimplePersonMethodAccessor
_p.DoSomething

End Class
End NameSpace

Now my PersonFacade must have a reference to BLL *AND* DLL otherwise the
properties and such in DLL wont be visible. (maybe my visibility is wrong)
How is this abstracting? I understand why the reference is needed to
BLL...but why DLL too? Shouldn't DLL be totally insulated from knowledge?

It seems a lot of the patterns I have been looking over work logically
well...until you throw in a datastore. Then the reasons for decorators or
bridges or strategy patterns disappear...

I have been looking into NHibernate..but I am working on a large project so
I am using dOOdads instead. But I want a good level of abstraction between
my web interface and my BLL thus the facade...But if I ever had to change
the backend implementation or the datalayer changed for some reason I need
to know that I am abstracted enough from the interface.

I have read Headfirst Design patterns. I have the Wrox Professional design
patterns book. But like I said none of them really tackle patterns from the
point of having a persistence layer. A lot of the reason for the some of the
patterns are invalidated(in my mind) when you have a datastore.
 
Back
Top