|
锁定老帖子 主题：为新的小型项目设计了一个架构，请批评指正
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-10-14
这贴实在该放到新手区，在这里讨论了这么久......
|
| 返回顶楼 | |
|
发表时间：2006-10-14
cjmm 写道 hehe,多说几句吧。
1 sql拼串是安全编程大忌 2 设计不是凭空想就能想出好的设计，没有比较长时间的编程经验是做不出好的设计的 3 建议使用spring框架 1、此话怎讲，我只知道拼接不能用String，那样效率低，如果不拼接我的参数怎么传，全部用PreparedStatement吗？ 2、我同意，我现在只是想确认一下我这样的做法是把业务逻辑的调用、实现和持久化分离了，能解决那两个耦合问题最好，不行的话先这么用也无妨，总有个不断改进的过程 3、小组成员对spring不熟悉，一上来就用我怕出问题 |
| 返回顶楼 | |
|
发表时间：2006-10-14
希望大家还是根据上页楼主贴出来的代码，想下怎么解决那两个问题，以前的这的相关帖子我们也看了，就是在那些基础上写的。
|
| 返回顶楼 | |
|
发表时间：2006-10-14
好吧，大佬们通常情况下不屑于来解答这类问题，我这个菜鸟今天没什么事，就略微说下我的看法。
1.你的addUser使用boolean作为返回值这种方式不是什么好设计，更为优雅的方法是抛出业务Exception
if (reg.addUser(user)) {
request.setAttribute("userName", userName);
request.setAttribute("userPwd", userPwd);
target = "/success.jsp";
} else {
target = "/failed.jsp";
}
这里很明显是很糟糕的代码。 2.使用PO/VO来传递数据不是笨拙的的方法，有更为优雅的数据转换方式，你们可以看下apache common-utils的组件，相信会受益良多。 3.是否划分接口，要看你是否会对抽取出来的接口有多个不同的实现，如果只有一个实现，还划分出接口，往往会导致更大的复杂性，我想没人会喜欢撰写和维护n多的factory吧？看下论坛上的其他文章，有很多关于这方面内容的精辟论述。 4.拼接SQL会导致sql注入攻击可能性，如果有一定数据库基础google一下就明白了，论坛上我记得robbin也发过相应的帖子。当然，不是说就永远不能拼接sql，当时要慎重考虑是否可能被sql注入攻击。 5.这类帖子希望以后能到新手区讨论。 |
| 返回顶楼 | |
|
发表时间：2006-10-14
引用 问题一在这个servlet中，接收用户输入并以领域对象的形式来传递，接收和传递数据的方式我总觉得很笨拙
可以通过反射机制实现一个帮助类来完成从request请求参数到“领域对象”属性的封装，从而化简这一过程。参考struts form/spring commandclass的封装过程 引用 问题二这样的方式有一个明显的问题，就是接口的实现和接口是耦合的（业务层和持久化层都是），尽管在这个项目里面并不是很大的问题，不过我还是想知道有没有比用factory模式加配置文件更好的方式，因为那样的话配置文件的维护简直是恶梦。
Illum 说的“3.是否划分接口，要看你是否会对抽取出来的接口有多个不同的实现，如果只有一个实现，还划分出接口，往往会导致更大的复杂性”。我也同意这一点，况且你前面也说过没有切换数据库的可能 不过采用接口和实现分离也是有好处的，比如可以增强注重设计的意识；通过接口，可以便于开发人员分工协作等等 另外采用factory模式，不一定非要引入“配置文件的维护简直是恶梦”的情况，大致可以这样实现 public class UserRegisterFactory {
public UserRegister getImplementInstance(){
return new UserRegisterImpl();
}
}
使用时如下 UserRegister reg = UserRegisterFactory.getImplementInstance(); 这样就可以避免配置文件复杂度，当需要调整接口的实现类时，可以通过修改Factory的获取实例方法进行调整，而不用去修改所有使用该实现对象的客户类部分；此外在获取方法中，可以做些优化，比如引入单例模式等等 |
| 返回顶楼 | |
|
发表时间：2006-10-14
谢谢楼上的解决办法，我咋就没想到。太笨了，让我再修改下
|
| 返回顶楼 | |
|
发表时间：2006-10-14
cjmm 写道 行为艺术家 写道 dao就是简单数据访问,我觉得是没有必要做一个类层次的.我感觉它的权责过轻了,实际使用时为一时方便又容易分派给它很多额外任务,所以有必要分开成两层Domain和Service.
我认为系统中各部分传递的数据都应该是Domain(也就是你说的model)中各类及其集合和组合,logic是对数据从内(java)向外(view)或从外向内的处理,service搭起流动对象与持久层之间的桥梁.我感觉这样比较清晰. 请问cjmm 怎么看?(PS:这段是后来改的,原文是楼上怎么看,回完贴才发现楼上换人了,Robbin是否觉得那个小CheckBox有些不妥啊) 加一个DAO层主要是从TDD的角度出发，对业务层进行测试时可以通过mock独立于数据库进行。 我model里面放的是没有业务逻辑只有getter和setter的POJO，在DAO层save/update/get得到的是model对象。 这样子的考虑事实上是把模型与逻辑完全分离。 service里面会对model进行进一步封装，model不是提供给web的对象。 举个例子，要对用户进行管理， package model;
public class User
{
private String name;
private String password;
private long lastLoginTime;
//以下是getter，setter和hashcode，toString,equals方法
}
package dao;
public interface UserDAO
{
model.User getUser(String name);
List getUsers();
void saveOrUpdateUser(model.User user);
void removeUser(model.User user);
}
package service.user;
public interface User
{
String getName();
String getPassword();
boolean validatePassword(String pwd);
void update();
}
public interface UserService
{
User getUser(String name);
User[] getUsers();
void createUser(String name, String pwd);
void removeUser(User user);
}
package service.user.impl
final class UserAdapter implements UserAdapter
{
...
}
final class UserService implements UserService
{
...
}
事实上在web层全部是通过接口得到对象，而在service层得实现中把model对象用adapter封装成适用于实际应用的对象提供给调用者，最大限度地在层次间进行解耦 虽然我们说法不同,做法还是相似的.但我在Service层搀杂了持久层和业务层的东西,不利于层次间解耦,我先想想吧.届时再讨论这个问题. |
| 返回顶楼 | |
|
发表时间：2006-10-14
关于用户存在检查是用If还是异常的讨论在这里:http://www.iteye.com/topic/2038
|
| 返回顶楼 | |
|
发表时间：2006-10-15
行为艺术家 写道 关于用户存在检查是用If还是异常的讨论在这里:http://www.iteye.com/topic/2038
嗯，谢谢，看了这个帖子很受用 |
| 返回顶楼 | |
|
发表时间：2006-10-15
JavaVision 写道 kryptonum 写道 cjmm 写道 hehe,多说几句吧。
1 sql拼串是安全编程大忌 2 设计不是凭空想就能想出好的设计，没有比较长时间的编程经验是做不出好的设计的 3 建议使用spring框架 1、此话怎讲，我只知道拼接不能用String，那样效率低，如果不拼接我的参数怎么传，全部用PreparedStatement吗？ 2、我同意，我现在只是想确认一下我这样的做法是把业务逻辑的调用、实现和持久化分离了，能解决那两个耦合问题最好，不行的话先这么用也无妨，总有个不断改进的过程 3、小组成员对spring不熟悉，一上来就用我怕出问题 1.当然，如果你学过jdbc编程的话，肯定知道statement是不推荐使用的 2。不要老想着解耦合，灵活，可扩展之类的，这东西也不是想出来，可以靠以后重构。 3。就像前面有人说得那样，架构设计不是想出来的，要有经验的。我看你们都还小，还是从最肮脏的做法开始吧。代价不会太大，用心的话，收获很多。 1、是的，不过以前不了解SQL注入的起因原来在这儿，已google 2&3、我们确实都还小，在开发上和各位前辈比起来差距很大，因为这些都需要一个积累的过程。我提出来这些问题的原因就是因为我们在一个很糟糕的分层架构下做了几个项目，觉得自己需要有所突破，这个目的已经达到了，楼上各位对我的设计和代码提出的问题我都会好好整理。 有些设计和代码上的问题是我现在的老师不会教我，凭我一人之力也很难想明白、设计好、编写好。在这里讨论的目的就在于发现问题，至于各位所说的"架构设计不是想出来的"我也认同，但是如果在起点就“南辕北辙”总不好。我很赞同行为艺术家的这句话：其实拿到论坛上探讨也是一种办法,有时候真理越辨越明的. 讨论者还可以相互学习.在下既然把设计和代码放上来了，各位就尽管挑毛病，我有准备，呵呵 |
| 返回顶楼 | |
