Yes, different people feel differently about integrating the data access
layer...but your properties SHOULD be merged with your methods...I don't
think there's many people who feel otherwise.
I normally keep my DAL separate, but only exposable through methods in my
class.
for example, I like to do
//in my User class
public static int GetUserById(int userId)
{
//use dal to access store
}
many people prefer not to have this in the same class, which si fine, but
your presentation layer shouldn't be talking directly to your DAL. It should
go through a business layer, whether tha'ts the core class or some component
class doesn't really matter. This way you can implement business rules
/functions inside these methods.
Karl
--
http://www.openmymind.net/ http://www.fuelindustries.com/
"dm1608" <dm1608@spam.net> wrote in message
news:egpuSpJOGHA.1288@TK2MSFTNGP09.phx.gbl...[color=blue]
> Thanks --
>
> I thought that the standard was not to merge the BAL and DAL simply so I
> could re-use either, if needed, for another project??
>
> I like your idea about JobSummaryData. I thought JobSummaryDataAccess
> seemed a bit long and blantently "Newbie" approach.
>
>
> "Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
> net> wrote in message news:ui9ksfJOGHA.3460@TK2MSFTNGP15.phx.gbl...[color=green]
>>I don't like the use of the word "class". Why don't you want to merge
>>your data with your behaviour (which you intentionally seem to not be
>>doing) (ie merging JobSummaryClass and JobSummaryComponent). There's more
>>debate about whether your DAL should or shouldn't be merged (I like to
>>merge it).
>>
>> Assuming you have good reason, I'd probably name them:
>>
>> JobSummaryData
>> JobSummary
>>
>> the name of your DAL isn't all that important since it should be internal
>> and not part of the exposed API. (your JobSummaryData could also be
>> internal depending on exactly how your building your stuff).
>> JobSummaryDataAccess :)
>>
>> Karl
>> --
>>
http://www.openmymind.net/
>>
http://www.fuelindustries.com/
>>
>>
>> "dm1608" <dm1608@spam.net> wrote in message
>> news:O4%23lwLJOGHA.3576@TK2MSFTNGP15.phx.gbl...[color=darkred]
>>> I'm relatively new to ASP.NET 2.0 and am struggling with trying to find
>>> the best naming convention for the BAL and DAL objects within my
>>> database. Does anyone have any recommendations or best practices for
>>> naming my objects?
>>>
>>> I currently have all my type classses simply called "JobSummaryClass" or
>>> "JobDetailsClass". These classes simply contain the public properties
>>> and the get/set functions for the object. Is this an appropriate naming
>>> convention?
>>>
>>> I then have a BAL class that I call simply JobSummaryComponent that
>>> contains all my BAL logic for the various classes.
>>>
>>> Finally, I have a DAL class that I call "JobSummary" that contains my
>>> DAL.
>>>
>>> It seems that my naming convention doesn't really represent whether its
>>> a BAL or DAL and I'm just wondernig if I'm doing this the best way. My
>>> current BAL for JobSummaryComponent contains the code for querying and
>>> using the JobSummaryClass and JobDetailsClass above. So my thought of
>>> calling this BAL JobSummaryComponent shoudl probably be renamed simply
>>> to JobComponentBAL or something.
>>>
>>> Also, should I create a separate source file per object or try and put
>>> all related objects/classes within same source??
>>>
>>> Opinions?
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]
