Wspólny model danych EF Code First dla ASP.NET MVC i WinForms

Witam
Chciałbym użyć modelu danych z ASP.NET (EF 6.1.3) w aplikacji WinForms. Chodzi głównie o binding do gridów przez bindingsource.

Obiekty zawierają listy obiektów. W modelu danych EF dla ASP.NET MVC są pokazywane w przykładach ICollection i List, HashSet itp. Natomiast w WinForms najlepiej działa (chyba) BindingList.
Czy to dobry pomysł, żeby w modelu dla ASP.NET zostawić ICollection w deklaracjach i tworzyć HashSet-y w konstruktorach a dla WinForms w deklaracjach i kontruktoracgh powstawiać BindingList-y i opakować to w jakieś definy?

Np coś takiego. Mądre to? Głupie? Ryzyka? Można jakoś inaczej, lepiej, dziedziczyć jakoś?

public class Faktura
    { 
        #if WINFORMS
        public virtual BindingList<FakturaItem> Items { get; set; }
        #endif
        #if ASPNET
        public virtual ICOllection<FakturaItem> Items { get; set; }
        #endif

        public Faktura()
        {
        #if WINFORMS
            Items = new BindingList<FakturaItem>();
        #endif
        #if ASPNET
            Items = new HashSet<FakturaItem>();
        #endif

        }
}

Model danych to model tego, co siedzi w bazie, jaki baza ma związek z technologią GUI?

To, co potrzebujesz, to dwa różne modele prezentacji dla obu typów aplikacji, czyli oddzielnych od modelu danych zestawów klas odpowiedzialnych za to, co będzie wyświetlane w GUI.

Dzięki za odpowiedź.
Związek ma taki, że w modelu w EF są definiowane relacje z wykorzystaniem różnych typów kolekcji. Jedne działają lepiej w ASP.NET a inne w WinForms ze względu na różnie obsługiwane np. wiązanie do obiektów prezentacji. Nie pisałem, że korzystam namiętnie z komponentów DevExpress-a w WinForms (w asp.net zresztą też) i dla kolekcji typu List są problemy z obsługa wielopoziomowych master-detail.

Może niejasno się wyraziłem, ale chodzi mi o to, że klasy z EF nie powinny nigdy trafiać do warstwy GUI. Tam powinny być zupełnie inne klasy, i to w tych innych klasach dostosowujesz typy danych do technologii GUI.

Tak. Myślałem o tym, ale IMHO to już jest decyzja projektowa. Nigdy to bardzo kategoryczne stwierdzenie ale dzięki za odpowiedzi.

Nie, to tylko Twoja (i wielu innych osób) opinia z czegoś tam wynikająca. Kiedyś były inne "powszechne prawdy". Ale to już mocno nie na temat. Tak czy siak dzięki za odpowiedzi, zastanowię się nad tym.

No dobra, kończąc, SRP czy ogólnie SOLID to nie jest dekalog, że jak nie stosujesz to pójdziesz do piekła. Jak mi z przemyślunku wyjdzie, że w danym przypadku nie ma sensu to nie stosuję.

Oczywiście, że nie pójdziesz do piekła. Nie stosując SOLID zrobisz sobie sam piekło na ziemi, jeśli lubisz, to nie ma sprawy.
Nie ma też obowiązku bycia dobrym programistą. Można całe życie cudować, wymyślać jakieś przedziwne mechanizmy, wynajdować koło na nowo, za każdym razem coraz bardziej kwadratowe... Twój wybór.