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
