Class design.... keeping it simple

Question

0.00/5 (No votes)

See more:

Hi all,

Firstly.... sorry for the length of this. Please keep reading.

I'm looking for some advice on how best to refactor a project that I am building in order to maintain the projects simplicity.

I'm building a blogging engine.... partly as a learning exercise and partly as all the open source solutions I've found are either feature incomplete or have been cobbled together out of code of varying (sometimes pretty poor) quality. The idea is that I can then give something back to the community.

I've started by building my data access layer using the repository pattern whilst utilizing generics to allow me to more easily add features to the engine.

On top of that I've defined a blog provider interface from which I can define custom providers to allow flexibliy of persistance methods (I'm defaulting with XML storage). These would then be called by a static service class which determines which provider to use based on a value in my web.config

The problem I am now having is with the complexity of these providers. Whilst the basic CRUD features are simple and interchangeable I've been
writing type specific methods to instruct my generic persistance classes.

This would be fine if I only had one or two types to persist but now I'm looking at host, blog, blogsettings, post, category, tag with more to follow.

This means that for every type I'm adding that's 4 maybe 5 methods to add to my provider interface, then to my abstract provider base class then to my providers. Then i have to add the methods to call the provider methods to my service class. It's all starting to get a bit silly.

My first thoughts would be to change my methods in my service class to accept a type parameter so rather than:

Blog SelectBlog (Guid id){
    provider.selectBlog(id);
}

and

Post SelectPost (Guid id){
    provider.selectPost(id);
}

I would instead use something like:

IEntity SelectObject (Type type, Guid id){
// IEntity is my basic interface required for all persistable types....
}

With another method in my class that would enumerate through known types in my project and choose the correct persistance method to call.

Whadya reckon?

Thanks for reading!

James

Posted 28-Jun-10 1:15am

JimBob SquarePants

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

E.F. Nijboer · Answer 1 · 2010-07-15T00:22:00

Hello JimBob,

Something I see is the method naming in the providers. Like the blog provider has a SelectBlog and a Post provider has a SelectPost method. If you have control over these providers I would recommend giving them generic names, like a simple method Select. You would then get the same as the CRUD features, a more generic way of methods that can be used.
Example: BlogProvider.select(guid);
Result : The Blog of type IEntity

You could then use a simple class holding these providers and use this, like:

IEntity blogEntity = ProviderCollection.Blog.select(guid);
IEntity postEntity = ProviderCollection.Post.select(guid);

For specific provider methods you can create properties that tell you what capabilities the provider supports. This is like the stream type. You could add properties that indicate if the provider supports specific methods. Like a method AddComment that could be available for a Blog and a Post. All should have a property CanComment that is only true for Blog and Post.

By the way. Providers blog and blogsettings are separated, but aren't the settings kind'a related to the specific blog provider used? Could blogsettings not just be a part of blog? So simply blog.settings? Also adding a property HasSettings to check if settings are supported. The settings itself could be a simple list of definitions with Name, Value and Type. A generic class could build a page to show and save these settings and this way provide generic setting capabilities for all classes that support this.

Well, maybe this text helps give you some ideas... or raises more questions than you had before ;)

Good luck!