SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Member
    Join Date
    Apr 2005
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Project structure

    Hi All,

    Hopefully just a quick question about project structure. I have been reading a nice tutorial I found linked off asp.net about n layered application design which I would like to try in my next project. I am separating out my data access layer, business logic layer and business objects into their own separate class library projects.

    My question is, if you have a number of unrelated functionalitys in your asp.net site each requiring a data access layer, business logic layer and its own set of business objects, would you lump them all together and have a single dal class library, a single bll and a single bo class library project? Or would you separate them out to that there was multiple class library projects for each layer, each specific to the functionality they provide?

    Hopefully that makes sense, I am just trying to figure out how best to structure my project as I have always been a bit lazy on this in the past.

    Thanks

  2. #2
    SitePoint Mentor NightStalker-DNS's Avatar
    Join Date
    Jul 2004
    Location
    Cape Town, South Africa
    Posts
    2,873
    Mentioned
    44 Post(s)
    Tagged
    0 Thread(s)
    hi. sorry 2 post a useless reply, but i was just also researching n-tier application. Could you plz post that link ur reading here so I can read thru it as well.

    Thanks

    Does anyone else also maybe have other usefull links on this subject and to maybe answer Lee134s Q?

    Thanks

  3. #3
    SitePoint Guru pinch's Avatar
    Join Date
    Mar 2005
    Posts
    688
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Lee, I think it depends on how big your project is and whether or not your different 'modules' are vastly different (have different connection strings, different caching preferences, etc). The architecture that I set up is relatively complex (really too complex for my application, but very flexible should I choose to expand it) and probably too lengthy to describe. Do you have a good reason why each of your different functionalities should be separated (I'm speaking about separation within the same layer).

  4. #4
    An average geek earl-grey's Avatar
    Join Date
    Mar 2005
    Location
    Ukraine
    Posts
    1,403
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How much decomposition should be applied depends on a particular case. But, generally speaking, smaller size your libraries are, more convenient it will be to reuse them separately in future.

  5. #5
    SitePoint Member
    Join Date
    Apr 2005
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    NightStalker, thats no problem at all, I am using two:

    http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416
    http://dotnetslackers.com/articles/a...fBlogoNET.aspx

    To Pinch and earl-grey, many thanks for the info. Actually, to answer your question, I actually have no particularly good reason at this point for separating them other than the fact that the functionalities are unrelated to eachother (they do completely different things and connect to different databases). The question was really to find out whether it is good practice when there is unrelated functionality as to whether it should be separated or not. You both seem to indicate that it would depend on the project. Do you have any general pointers or guidelines as to when separating something out to its own class library would be recommended?

  6. #6
    SitePoint Guru pinch's Avatar
    Join Date
    Mar 2005
    Posts
    688
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lee134 View Post
    NightStalker, thats no problem at all, I am using two:

    http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416
    http://dotnetslackers.com/articles/a...fBlogoNET.aspx

    To Pinch and earl-grey, many thanks for the info. Actually, to answer your question, I actually have no particularly good reason at this point for separating them other than the fact that the functionalities are unrelated to eachother (they do completely different things and connect to different databases). The question was really to find out whether it is good practice when there is unrelated functionality as to whether it should be separated or not. You both seem to indicate that it would depend on the project. Do you have any general pointers or guidelines as to when separating something out to its own class library would be recommended?
    Personally, I've never seen a solution with multiple DAL class libraries, but I admit I'm a bit of a notice. My project structure uses a single class library as the DAL, but implements different modules for the different functionalities. I just put the classes specific to one area of functionality into their own folder. When a domain object needs to utilize the DAL, it asked for an instance of a particular provider, which is configured in the web.config; each provider is specific to a particular module.

    As I said my design is somewhat too complicated to convey in a post; if you're interested it is outlined in this book. It sounds like this solution is in line with what you're trying to accomplish so you may want to give it a look, but others here may have a simpler solution.

  7. #7
    SitePoint Member
    Join Date
    Apr 2005
    Posts
    20
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ahh great, thanks for the guidance pinch, its much appreciated. I think that makes perfect sense in the project I am implementing. I will definatly look into purchasing that book also.

  8. #8
    An average geek earl-grey's Avatar
    Join Date
    Mar 2005
    Location
    Ukraine
    Posts
    1,403
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There's also a legendary book on application design topic: Design Patterns: Elements of Reusable Object-Oriented Software by Gang of Four.

    Samples are in C++/Smalltalk and aren't related to the web, but it's worth reading for anyone who considers him/herself a software architect, anyways.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •