Click here to Skip to main content
15,886,199 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi!
I am planning to design a project (n-tier) that is easy to customize and maintain without compromising efficiency.
Here is the draft of my (unique :)) design layout base on what I learned on how to built n-tier architecture.

The project is composed of 3 DLLs (+1 for Helper Classes):
1. BusinessLogic.dll (Compose of 2 subfolders ValueObjects(DTO) and BusinessObjects)

2. AppDomainLogic.dll (i put here the domain driven classes like registration, admission, sale service classes, will use the Business Objects and VOs)

3. DataAccessLayer.dll
here is the code:
C#
// in BusinessLogic.DLL, sub folder ValueObject
        public class Member
        {
            // getters and setters
            public string ID { get; set; }
            public string Name { get; set; }
        }

        // in BusinessLogic.DLL, sub folder Business Objects
        public class MemberBLL
        {
            public void AddNewMember(Member member)
            {
                new MemberDAL().SaveNewMember(member);
            }
            //side-question:
            //should I inherit the Member VO and do it like this
            //public void AddNewMember()
            //{
            //    new MemberDAL().SaveNewMember(this);
            //}
            // which is more effecient???
        }

        // in DataAccessLayer.DLL
        public class MemberDAL
        {
            public void SaveNewMember(Member member)
            {
                // Save to DB
            }
        }

        // in AppDomainLogic.DLL, base class
        public abstract class RegistrationTemplate
        {
            public virtual void RegisterNewMember(Member m)
            {
                new MemberBLL().AddNewMember(m);
            }
        }

        //Client 1 registration domain logic
        public class RegistrationForClient1 : RegistrationTemplate
        {
              // will use the template
        }

        // Client 2 registration domain logic
        public class RegistrationForClient2 : RegistrationTemplate
        {
            // overrides the template
            public override void RegisterNewMember(Member m)
            {
                // change the behavior of MemberBLL.AddNewMember
                // different implementation
            }
        }

        // UI Implementation for Client1
        static void Main(string[] args)
        {
            Member m = new Member()
            {
                ID = "1",
                Name = "John Mortred"
            };
            new RegistrationForClient1().RegisterNewMember(m);
        }

My priorities/Goals are:
1. Efficiency
2. Maintainable / Customizable / Reliable
3. RAD (fast development of the system)

My questions:
In your opinion,
1. Is the design flawed? how about code efficiency? performance?
2. Do I violate some rules on OOP archi or Tiered design?
3. Is this design Loosely/ Low coupled?
4. Can I achieve my Goals using this?
5. Suggestions?

thanks in advance :)
Posted
Updated 26-Jun-10 20:21pm
v7

Hi,

You can take a look at this following link. This sample will guide you to achieve your goal as you mentioned

http://code.msdn.microsoft.com/eisk[^]


Hope this will help.

Thanks
 
Share this answer
 
I guess your aim is to use the "domain driven design" approach; but what I can see from your code is that you are using the traditional data-centric approach(using dumb entity objects).
For example "Member" is an "anemic domain object"(see Martin Fowler PoEAA) with just data & no behavior whose associated behavior is done by OTHER (business,..) objects.
You can get useful info & links at http://en.wikipedia.org/wiki/Domain_driven_design[^]
Good luck ;)
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900