Working with ENUM

[Andrea Williams]

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

 

[Colin Basterfield]

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]

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]

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

 

[Lennin Arriola]

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