Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Is there a reason why your implementation of IFoo and the factory method that returns it cannot live in a separate assembly from the BusinessLayer (and thus you can reference this new assembly from all the client assemblies)? If there is a reason, is it possible that IFoo should be defined in the BusinessLayer as well (and thus not require references to the Interfaces assembly)?</p> <p>If your interface really does need to be accessible from more than the Business Layer, and the implementation really does rely on the Business Layer then you'll need to look at something a bit more than just the factory method. You could use some of the principles of Inversion of Control / Dependency Injection to get better separation of concerns.</p> <p>[Edit in response to subsequent answer from O.P.] The Factory Method is not, IMO, sufficient to be considered an IoC approach. What it's best for is encapsulating construction of a specific implementation, to either re-use in multiple places or simply to <a href="http://www.laputan.org/mud/mud.html#SweepingItUnderTheRug" rel="nofollow noreferrer">sweep it under the rug</a>. What's lacking for me is the breaking of dependencies: since your factory method is living in the same assembly as it's being called from, in order to change the concrete type returned, you'd need to recompile. Consider the difference between the following two:</p> <pre><code>public class FooConsumer1 { public void DoStuff() { IFoo myFoo = new Foo(); myFoo.Bar(); } } </code></pre> <p>and:</p> <pre><code>public class FooConsumer2 { public void DoStuff() { IFoo myFoo = FooFactory.getFoo(); myFoo.Bar(); } } public class FooFactory { public static IFoo GetFoo() { return new Foo(); } } </code></pre> <p>The advantage of the second is that if you create an IFoo in more than one place, you only have one place to change it when you create a SuperFoo class to replace Foo. Also, there is only one place to put logic if it will decide between two implementations dynamically in some way. Another advantage is that if the constructor is complicated/ugly, or requires some additional code to look up configuration settings or so on, then it hides all that away from the method that is using it.</p> <p>However, none of those are really (to my mind at least) helping you break the dependencies between this method and the concrete implementation it uses.</p>
    singulars
    1. This table or related slice is empty.
    1. POFactory Pattern Advice Needed Please
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USGiraffe
    1. USGiraffe
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload