2013-11-14 13 views
8

Mam następujące projekty w Visual rozwiązania Studio dla aplikacji:czynienia z teksty stałe gdy interfejsy są w odrębnym projekcie

  • Common - metody użytkowe i rozszerzenia
  • Podmioty - Rich Domain obiektów z logiki biznesowej konkretnej do instancji
  • - repozytoria danych Przechowalnie
  • DataServices - Cienki wrapper do repozytoriów zawiera specyficzną logikę biznesową nie do instancji
  • interfejsie es - Wszystkie interfejsy dla encji i repozytoriów

Powodem, dla którego umieściłem interfejsy w osobnym projekcie, jest unikanie odwołań do projektów kołowych. Dzięki temu dwa projekty mogą odwoływać się do wspólnego interfejsu, unikając zarówno odniesienia projektu do konkretnej realizacji.

Celowo nie dokonałem żadnych odniesień do projektu w projekcie Interfejsy, aby uniknąć odniesień do projektów kołowych. Tworzę interfejs dla klas zdefiniowanych w innych projektach, co pozwala mi odwoływać się do interfejsu obiektu, w przeciwieństwie do konkretnej implementacji w innych interfejsach.

Więc przykładem będzie:

namespace Acme.Entities 
{ 
    public class Person : IPerson 
    { 
     string Name { get; set; } 
    } 
} 
namespace Acme.Interfaces 
{ 
    public interface IPerson 
    { 
     string Name { get; set; } 
    } 
} 

namespace Acme.Interfaces 
{ 
    public interface ITeam 
    { 
     string Name { get; set; } 
     IPerson Leader { get; set; } 
    } 
} 

Kwestia Zabrakło mi na to, kiedy Interfejs odwołuje enum zdefiniowane w innym projekcie. Bez przesuwania wyliczenia ramach projektu interfejsy, nie jestem pewien, jak odwołać się do wyliczenia bez tworzenia odniesień projektu, na przykład:

namespace Acme.Entities 
{ 
    public enum Status 
    { 
     Unknown =0, 
     Active = 1, 
     Active = 2  
    } 
} 

namespace Acme.Interfaces 
{ 
    public interface IPerson 
    { 
     string Name { get; set; } 
     Acme.Entities.Status ActiveStatus { get; set; } 
    } 
} 

Acme.Entities.Status zawiedzie chyba odwołać projekt Acme.Entities , ale utworzy to okólnik, ponieważ Acme.Entities odwołuje się do projektu Interfaces.

+4

Dlaczego sprzeciwiasz się przeniesieniu enum do projektu Interface? –

+0

Muszę iść z @DStanley tutaj. Prawdopodobnie chcesz zmienić nazwę projektu 'Interfaces' na' Common'. –

Odpowiedz

9

Musisz przenieść definicję wyliczenia do projektu Interfejsy lub do oddzielnego projektu, do którego odnoszą się oba projekty.

Osobiście zachowałbym je w tym samym projekcie - posiadanie osobnego projektu tylko dla wyliczeń wydaje się przesadą.

+0

Pochylając się w kierunku umieszczania wyrażeń i interfejsów w tym samym projekcie, wszelkie sugestie dotyczące nazwy projektu, ponieważ "interfejsy" nie opisałyby już w pełni projektu? –

+0

"Często", jak wspomniano o @MichaelPerrenoud, wydaje się rozsądnym wyborem. – OnoSendai

+0

"Domena" byłaby moim pierwszym wyborem. –

2

Powiedziałbym, że twoje podstawowe typy danych (w tym enum s, interface s i class es) powinny znajdować się w jednym projekcie. Zatem twój projekt powinien zawierać ten i inne typy danych, które są typowe (być może abstract). Entities powinny nadal zawierać elementy specyficzne dla implementacji, które rozszerzają i/lub używają rzeczy podstawowych w Interfaces. Może też być sens scalenie Interfaces z projektem Common, ponieważ wspólna logika i wspólne dane często łączą się ze sobą.

+0

Mam ten sam problem, jeśli umieściłem interfejsy w projekcie wspólnym, ponieważ nie odwołuję się do innych projektów w trybie wspólnym, aby uniknąć problemu z odnośnikiem kołowym. –

+0

Zdecydowanie, interfejsy, wyliczenia i zajęcia. Nie jestem jednak pewien klas abstrakcyjnych. Nadal musisz przetestować każdą implementację wewnątrz klasy abstrakcyjnej. –

0

Jeśli prawidłowo zdefiniujesz komponenty i interfejsy, nigdy nie dostaniesz tego problemu.

Proponuję najpierw sprawdzić swój kod i swoją architekturę aplikacji z tych dwóch zasad:

http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Interface_segregation_principle

Domain Driven Desgin ---> Zasady bardzo impotent: http://en.wikipedia.org/wiki/Domain-driven_design

zgadzam się również z tym musisz przenieść Udziały SHARED do wspólnego IConstants.cs. Enum to nic innego jak stałe;

+0

"Emumie są niczym innym niż stałymi" Są czymś więcej niż stałymi. –

+1

@DStanley To jest filozoficzny komentarz, który niektórzy ludzie nie akceptują tego i inni widzą enum jako kolekcję const, a inni tego nie robią, ponieważ mogą stosować operacje na Enums itp. Nie będę angażował się w tę dyskusję. –

Powiązane problemy