oop - .NET Application Architecture - Which is the optimal assembly for this class? -

i have .net web application have taken over, had in past suffered business logic being in code behind pages , tied ui.

i have spent time refactoring, in particular moving data access code dedicated data access project "company.dataaccess" (for example). other logical portions of code have own assemblies too.

what i'm not comfortable with, placement of objects need shared across assemblies:

for example - in project "company.clientdataimport", have classes containing business logic import of client data.

one particular piece of functionality comprises code, client import format can mapped our default import format. so, have class "dataimportfieldmappinginfo" within "company.clientdataimport" assembly:

public class dataimportfieldmappinginfo {      int companyfieldname     {         get;         set;     }      int clientfieldname     {         get;         set;     } } 

these mappings stored in database, @ point, need populate collection instances of object.

one architecture aim, database io should handled "company.dataaccess".

i want "company.dataaccess" aware of class dataimportfieldmappinginfo can utilise class intended storing type of data, means "company.dataaccess" , "company.clientdataimport" both need aware of dataimportfieldmappinginfo can communicate using same classes.

my solution common problem far, use library called "company.domainentities" contains classes objects shared across other assemblies in application. works well, , assemblies can communicate in terms of same objects. classes contain properties, data containers opposed containing application logic.

what don't dataimportfieldmappinginfo data import concern, , believe should in namespace, , therefore in "company.clientdataimport" project. circular reference restrictions prevent however, have use "company.domainentities" project middle man.

is there wrong architecture, or common practice in sort of situation?

i tend agree marc; there's couple of other things might consider:

what constitutes "business logic" vs "data access" code vs simple data structures app "knows" about? @ first glance dataimportfieldmappinginfo looks might data access related think common structures (and more business orientated) putting them in common assembly make sense - assuming use them exchange data between different layers / assembilies.

the other view take all data repositories (which includes databases specific application external data sources external databases, files or systems) treated equally , accessed through interface - not through single concrete implementation. in case data specified in business logic / domain centered way , not data access / repository specific way. in case you'd define common data structures used app in common assembly.

edit:

in short, interfaces allow abstract out complexity , dependencies associated nasty stuff you'd rather not closely (and permanently) associated with.

the principle behind using interfaces dependency inversion (di). (there's no shortage of information - in fact might find there's too much). di goes along way helping build systems play nice stable dependencies principle.

the idea rather having business logic (assembly/s) depend on data access, have them both depend on interface; can swap out implementations anytime want. might have "real" data access component works against sql , "dummy" 1 returns dummy test data straight code.

when design interface idea design business logic / domain perspective - not technical one; although there cases that's appropriate. job of implementation (i.e: data access class implements interface) translate between business orientated interface , whatever strange data source it's dealing with. example, average sql based data provider might suck out data via datareader , convert in mybusiness.common.info.outstandingaccountscollection.

code structure

• common assembly (mybusiness.common) - contains data structures used exchange data between layers (e.g: mybusiness.common.info.outstandingaccount , mybusiness.common.info.outstandingaccountcollection classes).
• interface assemblies: might have several of these. if data access via 1 system (say sql) you'd have 1 (mybusiness.interfaces.dataaccessprovider), if have various system interface you'd want keep them seperate. mybusiness.interfaces.dataaccessprovider references common assembly because include 'info' types in it's contracts.
• concrete data access assembly(s): (mybusiness.dataaccess.sqldataaccessprovider). references common , interface assemblies.
• your business logic (mybusiness.businesslogic) references common , interface assemblies.

for more info (and diagrams) check out piece (self promotion alert): 5-layer architecture