类设计....保持简单 [英] Class design.... keeping it simple

问题描述

大家好，

首先....对此很长的时间感到抱歉.请继续阅读.

我正在寻找有关如何最好地重构我正在构建的项目以保持项目简单性的一些建议.

我正在构建一个博客引擎....部分是作为学习练习，部分是因为我发现的所有开放源代码解决方案要么功能不完整，要么由于质量不同(有时很差)的代码而被拼凑在一起.我的想法是，然后我可以回馈社区.

我首先使用存储库模式构建数据访问层，同时利用泛型使我能够更轻松地向引擎添加功能.

最重要的是，我定义了一个博客提供程序接口，从中可以定义自定义提供程序以允许灵活的持久化方法(我默认使用XML存储).然后，这些将由静态服务类调用，该服务类根据我的web.config中的值确定要使用哪个提供程序.
我现在遇到的问题是这些提供程序的复杂性.基本的CRUD功能既简单又可互换，但我一直
编写特定于类型的方法来指导我的通用持久性类.

如果我只有一种或两种类型可以保留，那很好，但是现在我正在寻找主机，博客，博客设置，帖子，类别，标签以及更多需要关注的内容.

这意味着，对于每种类型，我都会添加4种或5种方法添加到我的提供程序接口中，然后添加到我的抽象提供程序基类中，然后再添加到我的提供程序中.然后，我必须添加方法以将提供程序方法调用到我的服务类中.一切都开始变得愚蠢了.

我首先想到的是将服务类中的方法更改为接受类型参数，而不是:

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....
}

我班上的另一个方法将枚举项目中的已知类型，然后选择要调用的正确持久性方法.

Whadya估算?

感谢您的阅读！

James

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

推荐答案

你好JimBob，

我看到的是提供者中的方法命名.就像博客提供者有一个SelectBlog，而发布提供者有一个SelectPost方法.如果您可以控制这些提供程序，则建议您为它们提供通用名称，例如简单的Select方法.然后，您将获得与CRUD功能相同的功能，这是可以使用的更通用的方法.
示例:BlogProvider.select(guid);
结果:类型为IEntity
的Blog
然后，您可以使用包含这些提供程序的简单类，并使用它，例如:

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

对于特定的提供程序方法，您可以创建属性来告诉您提供程序支持哪些功能.这就像流类型.您可以添加指示提供者是否支持特定方法的属性.就像方法AddComment可以用于博客和帖子一样.所有对象都应具有CanComment属性，该属性仅适用于Blog和Post.

顺便一提.提供者的博客和博客设置是分开的，但是设置类型是否与所使用的特定博客提供者有关?博客设置不仅可以成为博客的一部分吗?那么只是blog.settings吗?还添加一个属性HasSettings来检查是否支持设置.设置本身可以是名称，值和类型的简单定义列表.通用类可以构建一个页面来显示和保存这些设置，并以此方式为所有支持此设置的类提供通用设置功能.

好吧，也许这段文字可以帮助您提出一些想法...或提出比以前更多的问题;)

祝你好运！

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!

这篇关于类设计....保持简单的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！