How to design my solution

Question

Hello,

I am writing a web application which will include several parts - interactive calendar, todo list, managing finances,...

How should I design my solution? I thought something like this: each part has 3 projects (main project, DAL, BLL). So in my case I would have 9 projects in my solution:

• List item
• Calendar
• CalendarDAL
• CalendarBLL
• Todo
• TodoDAL
• TodoBLL
• Money
• MoneyDAL
• MoneyBLL

Would this design be OK?

Also: where should web.config be? In it I have a connectionString which I would like to call from all DAL projects. Now I had web.config file in Calendar project and when I wanted to create dataAdapter in CalendarDAL with designer, I couldn't use existing connectionString from web.config.

Thanks

Answer 1

Unless you need to be able to separate and use the logic of this code in multiple applications, there is really no need to separate it into that many projects. It adds complexity but doesn't really add value. I used to separate the general BL library from the DL library but realized I wasn't really getting anything out of it...and I was making some things more annoying in the process. What is most important in separating code is the logical separation, not the physical separation into separate dlls.

Also, instead of breaking this up into separate web apps, put them in one. It will be a lot easier to develop and deploy. This allows you to use one web.config. If they are separate websites then create different web projects. If they are not, then don't.

[Edited] One thing I meant to add, which is important, is this: The question of how you should design this is actually too general to really come up with a real answer. Those thoughts are just my general thoughts on project organization, which is what the question really seemed to revolve around.

Answer 2

Honestly this doesn't sound right at all.

You description of the components isn't really all that...descriptive (can you tell us what you're system does?), but it sounds to me like what you really have is 4 component classes (List, ToDo, Calendar, Money) in one project, one (always one) DAL project, and possibly a business logic project. Probably you'll require others. I can't think of any meaning of "DLL" which makes sense in this context.

Nine projects for four logical objects is way too much. Separate code projects by what is logically associated: less is more.

Answer 3

read up on MVC or nTier programming.

three basic layers:

1. your view: the aspx web pages
2. a controller: allows the view to interact with the model (kinda like encapsulation) it's just one class that acts as a go between.
3. a model: in here is your database/xmldata and your functionality. this is where the magic happens.

work in increments. first make the most basic of websites. then add funtionality (one new feature at a time) , test it then move on.

Answer 4

In my opinion a good, layered .Net application architecture should have the following projects (structure) in the solution:

• Presentation layer: Here's where the web.config resides, your ASPX pages and user controls (ascx)
• Interface layer for the business logic layer: A layer containing exclusively interfaces of your business logic layer
• The business logic layer classes: The classes implementing the interfaces of the interface layer (point above)
• Interface layer for the data access logic: Again, exclusively interfaces of your data access layer
• The data access layer classes: The same as for the business layer; the implementations of the interfaces of the layer before

This sounds quite complicated but represents a good separation of the logical layers. So for instance you could exchange your business logic layer or more probably (and realistically) your data access layer DLL without changing anything above since everything is separated by the according interface layers from each other.

To what regards the separation of the different projects you mentioned (i.e. Calendar, Todo, etc...) I'm not really sure. The question you have to pose is to whether these things are independent applications or whether they belong together. Modularization is important, but has to be thought of very well. What I for instance would separate is like when you have a project with different kind of UI's, one for the Administrator and one for the normal user. Here it could make sense to just exchange the presentation layer, the rest below could remain the same. So you could for instance put the admin presentation layer + the other logical layers below inside a solution and the user UI presentation layer + the (same) logical layers in another solution. This may make sense when different development teams are developing each of the solutions.

In your case it seems to me more of being a single project, so I would just group them internally in different user controls/namespaces, but not create a project (-> DLL) for each of them. This adds just complexity without any major advantage.