Reputation: 11644
I have a sample ASP.NET application. The appliaction was developed as POC and not following any design and architectural standards.
Now I want to restructure the application. I can see some of the business logic and controls can be reused in future, such as login control.
I have two options for restructuring
I create a Utility DLL that will contain all such resusable code and another DLL that will contain all controls that can be reused.
I will create a separeate DLL for each type which can be reused e.g. Login control.
Which option is more better. Although I feel option 1 is good, but I need suggestion from experts.
Upvotes: 2
Views: 330
Reputation: 165
There are multiple ways to build an architecture. For instance you can create horizontal layers which put all GUI logic, business logic and data logic into separate layers. This is only from logical perspective. Where to put the layers is another question. From OO perspective you put them in at least different classes. You can decide to put them in different name spaces, different project/assemblies.
Just start slowly and refactor the most obvious parts. You can start putting the classes together in a part of the project (folder). Then change namespaces. Then put them in seperate project. Small actions will give you the chance to further consider your options. Each improvement is one.
So my advice is to first arrange classes and namespaces within the current project and so shape the logical parts. Maybe you need to add some interfaces here and there as well to separate the layers.
Upvotes: 1
Reputation: 753
I would go for a single assembly for your controls. You might create a new assembly for controls which you probably won't use soon or are very special.
I would categorize the business logic and make an assembly for each category.
Upvotes: 0
Reputation: 161831
I have no idea why you would want to keep a separate assembly per type. Don't do that.
Keep related functionality together in a single assembly. Look at how the .NET Framework is organized for examples. Note how, if you're not doing data access, you don't need to reference System.Data.dll
.
Upvotes: 2