CODEWITHSUNDEEP
.netdesign-patternsarchitectureoop
Or A
Or A

Reputation: 1789

.NET Project Architecture

I have sort of a philosophical question, which also need to consider the performance impact.

We are designing a new system with many sub-services that are not related to each other, yet, some may use each other (We are using unity to avoid any decoupling).

My main question is:

Thanks

Upvotes: 3

Views: 1110

Answers (8)

Sharon AS
Sharon AS

Reputation: 364

dlls load each time when we call functions in them. a big dll is not a good method. use smaller dlls, this will increase your pefomance.

Upvotes: 0

Patrick from NDepend team
Patrick from NDepend team

Reputation: 13842

.NET assemblies represent a physical artifact to package stuff you should never be used to architecture thing. In other words, use as few assemblies as possible, and preferably use only one .NET assembly. I'd advise to read these 2 white books on how to partition your code in assemblies, namespace, layers and components.

Upvotes: 0

Yann Schwartz
Yann Schwartz

Reputation: 5994

If your services are meant to be used together, group them in the same assembly. I've seen systems with zillions dll loaded (and solutions with zillions projects in it) with not a single instance where it was needed to cherry pick one assembly over any other. That does not preclude you from having decoupling and sane separations in namespaces.

As far as performance go, there's no real impact wrt number of dll's loaded (if you stay sane and don't go for thousands of them), but the impact is HUGE in developement if you stick with the default behavior of VS who loves to copy every reference in every project's bin/debug directory. On middle to big solutions (1000's of classes) the build process will be a lot longer and more frustrating.

Think of an assembly as a unit of deployment. If stuff is meant to be deployed together, stuff your stuff in the same assembly.

As a warning on how frustrating a project split in too many assemblies can be, look at the NUnit distribution. Over 30 different dll's, some you have to reference to be able to have unit tests, some you don't and you end up hunting for the types you need.

Upvotes: 3

ChrisW
ChrisW

Reputation: 56123

I like to develope a large system as several separate assemblies/DLLs, to promote there being an architecture. After that you can, if necessary/desirable, repackage the functionality into a single assembly before deploying it.

Upvotes: 2

Preet Sangha
Preet Sangha

Reputation: 65516

Don't optimse prematurely. I'd seperate the namespaces until you have a requirement to join them as a local optimisation.

Upvotes: 1

Paul
Paul

Reputation: 5406

Deployment is a big issue here. If all of this functionality is going to be deployed on a single machine I would suggest a single .dll, with different namespaces for behavioral separation. A single .dll will avoid many future issues with inter-.dll compatibility and greatly simplify deployment and installation.

Paul

Upvotes: 2

Reed Copsey
Reed Copsey

Reputation: 564641

I strongly prefer breaking them into separate projects and assemblies, when they are separate "services".

If you put everything into a single assembly, any client that wants to use any service will automatically load the entire assembly. By breaking them up, you can keep the memory usage down between separate client applications, and only load things as needed. Technically, loading one assembly is faster than loading many assemblies, but it is not faster if you're lazy loading assemblies in terms of perceived performance.

Once the assemblies are loaded, the performance should be identical.

Upvotes: 1

John MacIntyre
John MacIntyre

Reputation: 13031

Personally, I'd separate them into independent DLL projects to simplify development, testing, & maintenance.

Upvotes: 1

Related Questions