469,950 Members | 1,450 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,950 developers. It's quick & easy.

Working with ENUM

I'm working with C# and I'm setting up some ENUM's I have a data and
Business layer. I'm declaring a common enum for the Data Layer. The UI
layer references the Bus layer and the bus layer references the Data layer,
but I would like to have the enum exposed to all three. Is there a way to
trickle down that enum (Like class inheritance exposes classes) so that it
can be accessed from the Business layer and UI layers? My UI layer doesn't
talk to the data layer directly and I would like to avoid having to set up
the exact same enum in more than one of the layers.

I hope this is making sense. Let me know if I need to explain some more.

Thanks in advance,
Andrea
Nov 18 '05 #1
5 2459
Andrea,

Not sure if this was really the place to have posted this question, but
assuming it isn't a crosspost then just this once I'm sure the moderator
will take a leniant view :-)

Anyways there are obviously a number of ways of doing this, but one has to
ask why the UI layer needs an enum that is declared and I assume used in the
data layer, and the business layer from your question?

I assume that the UI is providing a means for the client to manipulate data
within an instance of a class? So once it is changed, the data becomes
'dirty', is it this change you are trying to 'flag' by exposing a StatusFlag
property as an ENUM?

I am working on something at the moment and I have an ObjectStatus enum
which is simply in it's own dll and I am referencing that from my ASP.NET UI
layer, my domain model (business layer), and my repositories (data layers).
If a value has changed then I simply mark the object 'dirty' by setting the
status flag to ObjectStatus.osDirty.

ObjectStatus is just declared as a public enum within the separate DLL.

Once I finish reading Domain Driven Design by Eric Evans I may well change
my mind.

HTH
Colin B
"Andrea Williams" <an*******@hotmail.IHATESpam.com> wrote in message
news:e8***************@TK2MSFTNGP12.phx.gbl...
I'm working with C# and I'm setting up some ENUM's I have a data and
Business layer. I'm declaring a common enum for the Data Layer. The UI
layer references the Bus layer and the bus layer references the Data layer, but I would like to have the enum exposed to all three. Is there a way to
trickle down that enum (Like class inheritance exposes classes) so that it
can be accessed from the Business layer and UI layers? My UI layer doesn't talk to the data layer directly and I would like to avoid having to set up
the exact same enum in more than one of the layers.

I hope this is making sense. Let me know if I need to explain some more.

Thanks in advance,
Andrea

Nov 18 '05 #2
Nope, no a cross-post, and it's for an ASP.NET app.

In my UI, I have a search box that allows the user to search based on five
different fields in a user record.

namespace DAL
{
public enum SearchBy
{
FirstName,
LastName,
EmailAddress,
SchoolOrg,
Status
}
}

I want to be able to pass a variable and use this in all the layers, but
really the DataLayer is the one that handles the search. I figured that it
would be handy to have these values in an ENUM instead of passing the field
name, since it's only going to handle these particular fields. However, if
I add the same enum to every layer, then if another field is added, I would
need to update all the layers.

So I guess my question is, what is the best way to pass this ENUM and only
declare it in one place. Since the UI doesn't have access to the DAL, that
doesn't seem like the best place, but the DAL isn't referencing any of the
other layers and I don't want it to know or care about the BL or UIL. But I
do want to make this enum available throughout the app.

Any ideas?

Andrea

"Colin Basterfield" <co**************@hotmail.com> wrote in message
news:eQ**************@TK2MSFTNGP10.phx.gbl...
Andrea,

Not sure if this was really the place to have posted this question, but
assuming it isn't a crosspost then just this once I'm sure the moderator
will take a leniant view :-)

Anyways there are obviously a number of ways of doing this, but one has to
ask why the UI layer needs an enum that is declared and I assume used in the data layer, and the business layer from your question?

I assume that the UI is providing a means for the client to manipulate data within an instance of a class? So once it is changed, the data becomes
'dirty', is it this change you are trying to 'flag' by exposing a StatusFlag property as an ENUM?

I am working on something at the moment and I have an ObjectStatus enum
which is simply in it's own dll and I am referencing that from my ASP.NET UI layer, my domain model (business layer), and my repositories (data layers). If a value has changed then I simply mark the object 'dirty' by setting the status flag to ObjectStatus.osDirty.

ObjectStatus is just declared as a public enum within the separate DLL.

Once I finish reading Domain Driven Design by Eric Evans I may well change
my mind.

HTH
Colin B
"Andrea Williams" <an*******@hotmail.IHATESpam.com> wrote in message
news:e8***************@TK2MSFTNGP12.phx.gbl...
I'm working with C# and I'm setting up some ENUM's I have a data and
Business layer. I'm declaring a common enum for the Data Layer. The UI
layer references the Bus layer and the bus layer references the Data

layer,
but I would like to have the enum exposed to all three. Is there a way to trickle down that enum (Like class inheritance exposes classes) so that it can be accessed from the Business layer and UI layers? My UI layer

doesn't
talk to the data layer directly and I would like to avoid having to set up the exact same enum in more than one of the layers.

I hope this is making sense. Let me know if I need to explain some more.
Thanks in advance,
Andrea


Nov 18 '05 #3
Hi,

On one hand I can see that this is indeed a workable approach if you
introduce a separate assembly to hold the ENUM.

However, and you can ignore this if you like or are too far down the track,
but you really ought to read Patterns of Enterprise Appplication
Architecture by Martin Fowler, because within here there is another approach
which is far cleaner and flexible, IMHO anyways, and that is to introduce
the idea of a Criteria class which one can use singularly or as part of a
list of Criteria to construct the ultimate query passed to the database.

This makes use of an overall Repository pattern object, which uses both
MetaData Mapping, and the Query Object underneath, so the client can
stipulate which fields of the class are to be used by inserting them into a
criteria object which is then passed to the Repository, and then in the
Criteria class you could attach all kinds of different things like equal.

So to work it to your requirement you could have a ClientRepository and one
of it's methods could be to create a list of all the clients whose
attributes are made up of 1..n search criteria, so in your application
coordinator, you could do, and this a bit of a hack but hopefully helps you
to understand what I burbling on about:

CriteriaList critList = new CriteriaList();
if txtFirstName.Text != ""
{
Criteria fnCriteria = new Criteria()
criteria.Equals(Client.FirstName, txtFirstName.Text)
critList.Add(fnCriteria)
}
etc...

Then you could do:

ClientRepository clientRep = new ClientRepository()
ClientList clientList = clientRep.Matching(critList)

Now within the ClientRepository you would implement the Matching method, and
it would have access to some kind of Client mapper class so it could find
the actual field name of Client.FirstName, and that would be used along with
the Criteria object to create an actual query object so that you ended up
with

select * from client where first_name = @firstName

where @firstName is set to whatever txtFirstName.Text.

Assuming you use Test Driven Development, and NUnit, you would implement an
in memory client list, that you loaded from an XML file or something, and
then use NUnit to test the internals of your client repository and the rest
eliminating both the ASP.NET UI, and the database.

There are lots of holes in this text, and I am sure I have glossed over bits
of it, unfortunately so does Mr Fowler occasionally, however as he says
tehre is no turnkey solution, but one thing I have learnt is that by using
TDD, NUnit and tiny steps it evolves into something great.

FWIW
Colin

"Andrea Williams" <an*******@hotmail.IHATESpam.com> wrote in message
news:eD**************@TK2MSFTNGP09.phx.gbl...
Nope, no a cross-post, and it's for an ASP.NET app.

In my UI, I have a search box that allows the user to search based on five
different fields in a user record.

namespace DAL
{
public enum SearchBy
{
FirstName,
LastName,
EmailAddress,
SchoolOrg,
Status
}
}

I want to be able to pass a variable and use this in all the layers, but
really the DataLayer is the one that handles the search. I figured that it would be handy to have these values in an ENUM instead of passing the field name, since it's only going to handle these particular fields. However, if I add the same enum to every layer, then if another field is added, I would need to update all the layers.

So I guess my question is, what is the best way to pass this ENUM and only
declare it in one place. Since the UI doesn't have access to the DAL, that doesn't seem like the best place, but the DAL isn't referencing any of the
other layers and I don't want it to know or care about the BL or UIL. But I do want to make this enum available throughout the app.

Any ideas?

Andrea

"Colin Basterfield" <co**************@hotmail.com> wrote in message
news:eQ**************@TK2MSFTNGP10.phx.gbl...
Andrea,

Not sure if this was really the place to have posted this question, but
assuming it isn't a crosspost then just this once I'm sure the moderator
will take a leniant view :-)

Anyways there are obviously a number of ways of doing this, but one has to
ask why the UI layer needs an enum that is declared and I assume used in the
data layer, and the business layer from your question?

I assume that the UI is providing a means for the client to manipulate

data
within an instance of a class? So once it is changed, the data becomes
'dirty', is it this change you are trying to 'flag' by exposing a

StatusFlag
property as an ENUM?

I am working on something at the moment and I have an ObjectStatus enum
which is simply in it's own dll and I am referencing that from my ASP.NET UI
layer, my domain model (business layer), and my repositories (data layers).
If a value has changed then I simply mark the object 'dirty' by setting

the
status flag to ObjectStatus.osDirty.

ObjectStatus is just declared as a public enum within the separate DLL.

Once I finish reading Domain Driven Design by Eric Evans I may well

change my mind.

HTH
Colin B
"Andrea Williams" <an*******@hotmail.IHATESpam.com> wrote in message
news:e8***************@TK2MSFTNGP12.phx.gbl...
I'm working with C# and I'm setting up some ENUM's I have a data and
Business layer. I'm declaring a common enum for the Data Layer. The UI layer references the Bus layer and the bus layer references the Data

layer,
but I would like to have the enum exposed to all three. Is there a way

to trickle down that enum (Like class inheritance exposes classes) so
that it can be accessed from the Business layer and UI layers? My UI layer doesn't
talk to the data layer directly and I would like to avoid having to
set up the exact same enum in more than one of the layers.

I hope this is making sense. Let me know if I need to explain some more.
Thanks in advance,
Andrea



Nov 18 '05 #4
I would create another assembly (i.e. Common) that all other layers
reference(DAL,BL,UI...), and put in there the common structures, constants
and enums.

Lennin
Nov 18 '05 #5
Yes that is what I was saying amongst my ramblings...

However my pair programmer always questions everything I suggest and
seemingly it is rubbing off, finally...:-)

"Lennin Arriola" <no@spam.com> wrote in message
news:ea**************@TK2MSFTNGP11.phx.gbl...
I would create another assembly (i.e. Common) that all other layers
reference(DAL,BL,UI...), and put in there the common structures, constants
and enums.

Lennin

Nov 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by Andreas Huber | last post: by
31 posts views Thread by Michael C | last post: by
1 post views Thread by Randy | last post: by
2 posts views Thread by Randy | last post: by
9 posts views Thread by Simon | last post: by
34 posts views Thread by Steven Nagy | last post: by
3 posts views Thread by Chevron Boyde | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.