I've built a CMS using entity framework, but I've recently begun laying the foundations (i.e. practicing with examples to increase my understanding) for re-creating it using as much seperation of concerns, best practices and design patterns that I can.
Please can you tell me if the way I'm going to go about it is correct?
I will have the following projects:
Contracts (service contract interfaces)
DataContracts (DTOs)
HTTPHost (HTTP host for service, WCF)
Service (contains all concrete implementations of the services as defined in the datacontract project)
ServiceProxy (gateway into the app that all clients appsc will use, also contains facades)
Infrastructure (Unit of work implementation, UOW interface, UOWrepository interface, query translation (still learning about that bit))
Model (model layer,holds POCO objects independant of entity framework, object factories, repository interfaces)
Repository (DAL - holds entity framework edmx, repository implementations, 1 per entity)
UI.Web (presentation layer)
Plus test projects for each of the above.
The patters I plan to use are:
Repository
Domain model
Reservation (less likely to be useful)
Idempotent (mainly with caching)
Document message
Liskov Substitution Principle
Dependency Injection and Inversion of control container
Object factories
Those are the big ones, anythign else I guess I'll decide as I come across an appropriate scenario.
I do feel like I'm going a bit overkill in some respects, but I want the app to be as scaleable as possible sine it's not a one off, I'll probably use it for every website I create in the future.
I feel like there is a little duplication of object properties between the edmx, POCO classes, service proxy classes and data contracts (DTOs), though I don't think this is really avoidable if I want true seperation of concerns.
In terms of the Service project, I was originally planning to create 1 service per entity, but that seems excessive. I'm not sure of any other way to divide up the functionality.
Just a single service to control everything doesn't seem like a great idea either.
How do you decide to introduce services in your projects?
I do feel like I'm going a bit overkill in some respects, but I want the app to be as scaleable as possible sine it's not a one off, I'll probably use it for every website I create in the futur
This overkill totally depends on your website project. If it is a standard corporate type website i would not have that level of granularity. I would combine some projects into one eg. have one project for contracs/dtos/service (for instance service layer)
stevex33
I feel like there is a little duplication of object properties between the edmx, POCO classes, service proxy classes and data contracts (DTOs), though I don't think this is really avoidable if I want true seperation of concerns.
I wouldn' worry about the duplication of objects i.e POCO, DTOs. I recommend you to use automapper to convert your pocos to dtos as it can do it with fewer lines of code when compared to manual mapping of the objecs
stevex33
In terms of the Service project, I was originally planning to create 1 service per entity, but that seems excessive. I'm not sure of any other way to divide up the functionality.
I think one service per entity is too much. In most cases the one service requires communication with multiple repositories as the job of the service is to expose the business functionality via soap/rest. I would create one service per business functionality
or core independent module in which you will inject the repositories you need.
stevex33
Am I on the right track?
You are on the right track. Start playing around with it and you will soon see the things that you need or don't need. You can always start with what you have defined here and then refactor as and when required. After all it should be easy to refactor the
project which is the sole point of SoC
Hope it helps
Please don't forget to mark this as "ANSWER." "Sharing is caring..."
stevex33
Member
356 Points
337 Posts
Is my website structure plan okay?
Jan 22, 2012 06:50 PM|LINK
Hi,
I've built a CMS using entity framework, but I've recently begun laying the foundations (i.e. practicing with examples to increase my understanding) for re-creating it using as much seperation of concerns, best practices and design patterns that I can.
Please can you tell me if the way I'm going to go about it is correct?
I will have the following projects:
Contracts (service contract interfaces)
DataContracts (DTOs)
HTTPHost (HTTP host for service, WCF)
Service (contains all concrete implementations of the services as defined in the datacontract project)
ServiceProxy (gateway into the app that all clients appsc will use, also contains facades)
Infrastructure (Unit of work implementation, UOW interface, UOWrepository interface, query translation (still learning about that bit))
Model (model layer,holds POCO objects independant of entity framework, object factories, repository interfaces)
Repository (DAL - holds entity framework edmx, repository implementations, 1 per entity)
UI.Web (presentation layer)
Plus test projects for each of the above.
The patters I plan to use are:
Repository
Domain model
Reservation (less likely to be useful)
Idempotent (mainly with caching)
Document message
Liskov Substitution Principle
Dependency Injection and Inversion of control container
Object factories
Those are the big ones, anythign else I guess I'll decide as I come across an appropriate scenario.
I do feel like I'm going a bit overkill in some respects, but I want the app to be as scaleable as possible sine it's not a one off, I'll probably use it for every website I create in the future.
I feel like there is a little duplication of object properties between the edmx, POCO classes, service proxy classes and data contracts (DTOs), though I don't think this is really avoidable if I want true seperation of concerns.
In terms of the Service project, I was originally planning to create 1 service per entity, but that seems excessive. I'm not sure of any other way to divide up the functionality.
Just a single service to control everything doesn't seem like a great idea either.
How do you decide to introduce services in your projects?
What do you think?
Am I on the right track?
Angad Bhat
Member
593 Points
146 Posts
Re: Is my website structure plan okay?
Feb 23, 2012 09:14 AM|LINK
Hi,
This overkill totally depends on your website project. If it is a standard corporate type website i would not have that level of granularity. I would combine some projects into one eg. have one project for contracs/dtos/service (for instance service layer)
I wouldn' worry about the duplication of objects i.e POCO, DTOs. I recommend you to use automapper to convert your pocos to dtos as it can do it with fewer lines of code when compared to manual mapping of the objecs
I think one service per entity is too much. In most cases the one service requires communication with multiple repositories as the job of the service is to expose the business functionality via soap/rest. I would create one service per business functionality or core independent module in which you will inject the repositories you need.
You are on the right track. Start playing around with it and you will soon see the things that you need or don't need. You can always start with what you have defined here and then refactor as and when required. After all it should be easy to refactor the project which is the sole point of SoC
Hope it helps
"Sharing is caring..."
Thank you!