2

I'm currently building a large web project, trying to do all the right things, splitting things into facades, services, DAO's (repositories), helpers etc

Also using DI with Ninject

Now, maybe this is just becuase it's near the start of the project, but it feels like it's taking an eternity just to setup simple calls in the db?

Every time I want to make a new call, or do something, it takes writing 4 methods minimum through each of the service layers, passing things all the way back up etc.. Every time you change something in the db layer, you have to replicate the change manually through the domain objects, as well as updating the methods that manually convert DAO objects to domain objects (using a partial class to accept DomainObjects in the constructor of a DaoObject, and a ToDomainObject method on each DaoObject)

Looping through each DaoObject to convert it into a domain object at the end of each reading DAO method feels messy.

We're using entity framework, DBfirst. Is there anything clever that we can do to make this process more DRY OR do we just have to wait until our basic groundwork of our app is built, and then things will start to feel easier becuase most of the plumbing is already layed down etc. And especially it will be good, when you want to make new services by combining existing ones.

Partiuclarly the manual re-creation of DAO objects in the Business Logic layer feels bloated, BUT I can understand that the actual way to think about it is that the DAO layer is actually mapping to the business layer, it just feels slow compared to using the Context Designer. IE the business layer dictates what data it needs, without caring where it actually comes from.

Any help would be gratefully appreciated.

Improve this question

2 Answers 2

Reset to default
1

One thing that will definitely speed up the time it takes you to add new functionality, is using AutoMapper to automatically convert your DAO into a domain object. No more boring manual property mapping!

Having all layers separated nicely does bring some extra plumbing you have to do, but you get every logical component cleanly separated, easy to test, easy to be replaced. Being a large project, I think the overhead will definitely pay of in the long term.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Look at T4 template generation capabilities. It can be used to generate\regenerate entities based on changes to DAO.

Look at http://www.blogfor.net/2009/09/03/generating-business-layer-code-t4-against-a-linq-to-sql-dal/

and

http://imaginarydevelopment.blogspot.in/2010/01/t4-generates-my-business-objects-for-me.html

to get some ideas.

Improve this answer

2 Comments

How does this solution compare to autoMapper?
Automapper makes things DRY(er), T4 templates are a short-cut for typing. Generated code is generally not DRY at all. But DRY code is not a goal in itself. The goal is increased maintainability. Both T4 and AM can serve that goal.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.