想请教一下大家关于IDAL层的问题

[HerryDong]

最近需要写一个三层，所以先写了个测试的代码，一开始在定义接口成员时我是这么定义的：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using WebApp.Model;

namespace WebApp.IDAL
{
    public interface IStudentService
    {
        IList<StudentEntity> GetEntities();

        IList<StudentEntity> GetEntitiesByAge(int age);

        IList<StudentEntity> GetEntitiesByName(string name);

        IList<StudentEntity> GetEntitiesByGender(string gender);
    }
}

但是前端界面会涉及到条件组合查询，那么理论上可能存在的组合情况就非常多，这种情况下个人认为上面这种写法就不是很明智，一是需要定义的方法太多，代码很臃肿，二是程序扩展性也不强，于是参照其他同志的代码，发现有如下写法：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using WebApp.Model;

namespace WebApp.IDAL
{
    public interface IStudentService
    {
        IList<StudentEntity> GetEntities(string condition);
    }
}

个人觉得这种写法不错，如果condition为空，则查询全部实体，反之根据条件进行查询，但这种写法需要在逻辑层里进行条件语句的拼接，个人觉得在某种程度上好像又有点违背三层的初衷，所以希望大家能提一下意见

[啥都不懂所以不当程序猿]

反正一些小项目懒得用三层

[qq_34057056]

无聊得很

[正怒月神]

两种方法都可以。 其实我感觉都无所谓。不用过度封装。 比如说，View1 有3个条件的组合查找。 那么方法可能是 Get1(a,b,c)然后自己判断a,b,c拼接的sql语句 然后View2 是通过另外的2个组合条件 Get2(c,d)

[HerryDong]

引用 3 楼 正怒月神 的回复:

两种方法都可以。
其实我感觉都无所谓。不用过度封装。

比如说，View1 有3个条件的组合查找。
那么方法可能是 Get1(a,b,c)然后自己判断a,b,c拼接的sql语句
然后View2 是通过另外的2个组合条件
Get2(c,d)

有道理，这也是个方法，还有我现在觉得在BLL里进行SQL条件拼接是不是有点越俎代庖？

[正怒月神]

引用 4 楼 HerryDong 的回复:

[quote=引用 3 楼 正怒月神 的回复:] 两种方法都可以。 其实我感觉都无所谓。不用过度封装。 比如说，View1 有3个条件的组合查找。 那么方法可能是 Get1(a,b,c)然后自己判断a,b,c拼接的sql语句 然后View2 是通过另外的2个组合条件 Get2(c,d)

有道理，这也是个方法，还有我现在觉得在BLL里进行SQL条件拼接是不是有点越俎代庖？[/quote] 有，正常来说，dal控制数据访问。 bll只关心逻辑代码。