471,325 Members | 1,654 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

Factory class - DA, BL, or UI layer?

Which layer should a Factory class go in?

DA - Data Access
BL - Business Logic
UI - User Interface

??
Feb 24 '06 #1
8 4619
The same layer as the object it is designed to create. Put it anywhere
else will introduce unnecessary coupling between layers.

Feb 24 '06 #2
"deko" <de**@nospam.com> a écrit dans le message de news:
_J******************************@comcast.com...

| Which layer should a Factory class go in?
|
| DA - Data Access
| BL - Business Logic
| UI - User Interface

That would depend on whether its a Data Connection factory, a Business
object factory or a UI Widget factory.

Factories are a design pattern that can be used in all sorts of situations.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 24 '06 #3
> The same layer as the object it is designed to create. Put it anywhere
else will introduce unnecessary coupling between layers.


So, should I have a factory in each layer (if needed), like this:

FactoryDA.cs
FactoryBL.cs
FactoryUI.cs

??
Feb 24 '06 #4
"deko" <de**@nospam.com> a écrit dans le message de news:
TY******************************@comcast.com...

|> The same layer as the object it is designed to create. Put it anywhere
| > else will introduce unnecessary coupling between layers.
|
| So, should I have a factory in each layer (if needed), like this:
|
| FactoryDA.cs
| FactoryBL.cs
| FactoryUI.cs

Not strictly, no. The Class Factory design pattern can be used for many
different purposes.

Sometimes, you don't need any factories, sometimes you will need more than
one in a layer.

There is no relationship between factories and layers, a class factory is
related to a given class hierarchy where you define abstract behaviour that
will be implemented by differing classes from that hierarchy.

My UI layer could have a form factory, the MVP layer would have an
interactor factory, a presenter factory, a model factory, possibly a view
factory, etc... The business layer could have all sorts of factories,
depending on the nature of the business classes. The data layer could also
have a SQL generator factrory, a connection factory and others.

Google for Design Patterns, Class Factory for examples of whre you could use
a factory.

But *don't* think that you *have* to have a factory in each layer or even at
all. Factories are not essential in an application, unless you really have a
need for them.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 24 '06 #5
> |> The same layer as the object it is designed to create. Put it anywhere
| > else will introduce unnecessary coupling between layers.
|
| So, should I have a factory in each layer (if needed), like this:
|
| FactoryDA.cs
| FactoryBL.cs
| FactoryUI.cs

Not strictly, no. The Class Factory design pattern can be used for many
different purposes.
And those purposes can vary within a layer?
There is no relationship between factories and layers, a class factory is
related to a given class hierarchy where you define abstract behaviour
that
will be implemented by differing classes from that hierarchy.


So it would be more appropriate to designate factories according to purpose:

in the DA layer:
FactoryDataset
FactoryDataTable

in the BL layer:
FactorySomeObject
FactorySomeOtherObject

in the UI layer:
FactorySomeControl
FactorySomeForm

Is this correct?

Feb 24 '06 #6
"deko" <de**@nospam.com> a écrit dans le message de news:
ve********************@comcast.com...

| And those purposes can vary within a layer?

Certainly

| So it would be more appropriate to designate factories according to
purpose:
|
| in the DA layer:
| FactoryDataset
| FactoryDataTable
|
| in the BL layer:
| FactorySomeObject
| FactorySomeOtherObject
|
| in the UI layer:
| FactorySomeControl
| FactorySomeForm
|
| Is this correct?

Yes, but don't fall into the trap of creating factories just because you
can. They are only really suitable for situations where you have a defined
hierarchy that is intended to be used in a polymorphic way from an abstract
or virtual base class.

If you don't have such hierarchies, then don't try to use class factories.
And don't try to design hierarchies just so that you can create a factory
:-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 24 '06 #7
> | So it would be more appropriate to designate factories according to
purpose:
|
| in the DA layer:
| FactoryDataset
| FactoryDataTable
|
| in the BL layer:
| FactorySomeObject
| FactorySomeOtherObject
|
| in the UI layer:
| FactorySomeControl
| FactorySomeForm
|
| Is this correct?

They are only really suitable for
rather, best suited for
situations where you have a defined
hierarchy that is intended to be used in a polymorphic way from an
abstract
or virtual base class.

If you don't have such hierarchies, then don't try to use class factories.
And don't try to design hierarchies just so that you can create a factory


I am intent on using a factory class, and will kill anyone that gets in my
way.

Feb 24 '06 #8
"deko" <de**@nospam.com> a écrit dans le message de news:
c4********************@comcast.com...

| rather, best suited for

furry nuff.

| I am intent on using a factory class, and will kill anyone that gets in my
| way.

Then don't let me stand in your way :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 24 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Ryan Mitchley | last post: by
4 posts views Thread by max | last post: by
2 posts views Thread by Julia | last post: by
3 posts views Thread by Andy | last post: by
4 posts views Thread by anonymous.user0 | last post: by
1 post views Thread by guhar1 | last post: by
6 posts views Thread by =?Utf-8?B?cml2YWxAbmV3c2dyb3Vwcy5ub3NwYW0=?= | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.