In an architecture, does the number of Dlls influence performance? Scalability?

Asked

Viewed 318 times

5

I have the habit of creating my Solution like this:

Entity - Class Library (Classes, entities)

Utils - Class Library (Classes of support, security, generate xml, in short, all kinds of functions)

Repository - Class de Repository ( Repository Patterns)

Map - Class Libary - ORM Mapping Classes, be it Nhibernate or Entity using Fluent API

Test - Test

Web Project - Here my web project, if I want to separate in "module" use the areas. (Modules = Financial, Stock, Billing, etc)

I use this structure regardless of the size of the project, whether small or giant

My question is: In an architecture, does the number of dll’s influence performance? scalability? Leaving like this would be bad if my project grew?

Or it would be better to create a library class for each module (one library class for financial module, one for billing, and so on. As well as web project, a web project for finance, billing, etc.

Links about architecture are welcome.

2 answers

7


The only problem with multiple Dlls is a slight time increase when starting the application, as all Dlls will be located and their dependencies resolved, but it’s not worth worrying about this performance impact.

2

The best for maintenance is you really separate, each project with your responsibility.

  • Project - Layer - Data Access (Entity)
  • Project - Layer - Utils (dll generic)
  • Projects - Layer - UI

But it should also have a good sense and not separate everything. in 200 projects. For example in your case I would leave Entity and ORM all together, after all are the same things.

Utils would leave together with BLL (Entity Manipulation Classes)

Interesting is also to check what each Class its does, example does not create a very generic class. it is better to have several classes each doing only 1 single thing. Read on: Single responsibility.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.