ASP.NET MVC (Modèle de domaine, dépôt, Fluent, Services - Structure pour mon projet)

Question

Dans mon application Web ASP.NET MVC, je:

• Modèle de domaine, créé par LINQ to SQL

• Référentiels tels que

  UserRepository et OrderRepository

• IQueryable Fluents comme IQueryable Extension Des méthodes telles que

  public IQueryable<Order> GetNewOrders(this IQueryable<Order>)

• services tels que

  UserService et OrderService

• Classes utilitaires et méthodes d'extension telles que

  CryptoUtility (faisant Hashage etc.) et cordes, etc. extensions

• ViewModels qui sont spéciaux pour chaque vue MVC

• Le projet ASP.NET MVC lui-même (contrôleurs, vues)

Je cherche la meilleure structure de projet/organisation pour mon cas, en particulier séparer en différents assemblages et comment les dépendances devraient ressembler entre ces couches. Malheureusement, les ressources Web ne vont pas dans les détails. Un indice: Actuellement Repository, Services, IQueryable Fluents etc. fonctionnent directement sur l'implémentation du modèle de domaine, je n'ai pas de définition d'interface pour eux. Je l'ai jugé inutile, mais peut-être est-ce nécessaire pour un couplage lâche? Mes services ont une interface (par exemple IOrderService) et mes référentiels implémentent IRepository < T>. Appréciez votre contribution sur l'organisation concise, et surtout quelle couche devrait dépendre de ce que l'organisation de l'assemblée . Je vous remercie!

Answer 1

Vous voudrez peut-être vérifier s#arp architecture pour voir comment ils structurent les choses. Il utilise NHibernate et leurs repos sont un peu directement liés à eux, vous devrez donc le modifier.

Answer 2

Un couple de différents projets ne vont plus en détail à ce sujet (mais vous l'esprit il faut aussi un effort pour comprendre vraiment comment les différentes parties travaillent ensemble)

• S#arp architecture
• Code camp server utilisant the onion architecture
• Rob Connery storefront screencast serries

Answer 3

Je regardais l'article de Jeffrey Palermo o n l'architecture de l'oignon here.Cette architecture de base fonctionne bien dans n'importe quel projet et vous permettra de séparer votre projet principal (couche de domaine, persistance, etc.) de votre projet web. Nous l'utilisons avec MVC/StructureMap/FluentNHibernate et avons eu beaucoup de succès.

Nous finissons par avoir une structure similaire à celle ci-dessous.

> trunk 
    + build (build scripts) 
    + lib (external libraries) 
    > src (source code)  
    >> Organization.App (solution name) 
    >> Organization.App.Core (code library) 
     + Config 
     > Domain 
      > Model 
      > Persistence 
      > Queries 
      > Services 
     > Persistence 
     > Services 
    >> Organization.App.Web (mvc web app) 
     > Assets 
      + Images 
      + Scripts 
      + Stylesheets 
     + Controllers 
     + Views 
     + ViewModels 

C'est l'idée de base. L'application Web fait référence à l'application de base pour les entités de domaine, notre référentiel/unité de travail. Consultez this older project on google code pour un exemple similaire. La grande partie à ce sujet est que nous avons été en mesure d'ajouter de nouveaux types de projets «UI» à la même solution et de réutiliser notre projet de base comme prévu. Comme une application de console ou une deuxième application Web, ou tout ce dont vous avez besoin.