我想制作一个完美的自定义DAL(数据抽象层)类,用于我的所有项目.
我搜索了互联网并找到了一些样本,但我不知道哪种方法最好.
它要做[Attributes]吗?或者使用<Generics>或其他什么?
所以,请给我一个头条,我会从那里继续.
再次感谢并原谅我的语言.
我是否正确使用NHibernate(或任何其他ORM)消除了DAL的必要性?或不?
在我的公司,我必须使用Bll,Dal和模型层来创建具有数据库的应用程序.
我在学校学到了每个数据表都应该是我模型中的一个对象.所以我创建了我的数据库的整个模型.此外,我已经了解到,对于每个表(或模型对象),都应该在DAL中创建一个DAO.所以我这样做.
现在我坚持使用BLL课程.我可以为每个DAO/ModelObject编写BLLclass,或者我可以编写一个BLLclass,它结合了一些(逻辑)DAO ......或者我只能写一个Bllclass来管理所有东西.(这最后一个我确定它不是最好的方式..)
处理这个Bll'问题'的最佳做法是什么?
还有第二个问题.如果一个bll需要来自另一个表负责的表内容,那么获取内容的最佳方式是什么?去问负责任的BLL或直接去DAO?
我在过去两个月里一直在努力解决这些问题,我不知道处理它的最佳方法是什么.
对不起,我的英语很差.
好吧,我现在正在考虑DDD方法,听起来不错但是......有一个小问题.DDD表示,域模型层与数据访问层(以及所有其他层)完全分离.因此,当DAL将保存一些业务对象时,它将只能访问此对象的公共属性.现在的问题是:
我们怎样才能保证(一般来说)对象的一组公共数据是我们以后需要还原对象的全部内容?
例
我们有以下业务规则:
这是一个描述这些规则的纯POCO:
public class BusinessObject
{
private string _user;
private string _domain;
public BusinessObject(string user, string domain)
{
_user = user;
_domain = domain;
}
public string Email
{
get { return _user + "@" + _domain; }
}
}
Run Code Online (Sandbox Code Playgroud)
因此,在某个时刻,DAL会将此对象保存到外部存储(即SQL数据库).显然,DAL会将"Email"属性保存到DB中的关联字段.一切都会正常工作,直到我们要求DAL恢复对象.DAL如何做到这一点?对象必须至少具有"电子邮件"字段的公共设置器.就像是
public string Email
{
set
{
string[] s = value.Split("@");
_user = s[0];
_domain = s[1];
}
}
Run Code Online (Sandbox Code Playgroud)
实际上,该对象将具有"User"和"Domain"字段以及方法GetEmail()的公共getter/setter.但是停下来.我不希望我的POCO拥有这样的功能!它没有业务规则.必须执行此操作才能保存/恢复对象.
我看到另一种选择.可以要求作为DAL一部分的ORM存储恢复对象所需的所有私有字段.但是,如果我们想要将域模型与DAL分开,则这是不可能的.DAL不能依赖业务对象的某些私有成员.
我能看到的唯一解决方法是使用一些系统级工具,可以为我们创建对象转储,并可以随时从此转储中恢复对象.除了对象的公共属性之外,DAL必须将此转储放入存储.因此,当DAL需要从存储中恢复对象时,它将使用转储.当DAL执行不需要实例化对象的操作时(即大多数link2sql查询),可以使用保存到存储的公共属性.
我做错了吗?我需要阅读更多内容吗?关于一些模式,ORM可能吗?
我想为我的数据访问层编写单元测试,以确保一切正常.问题是,我应该在测试中加入什么样的东西?
DAL是一个静态Repository类,它隐藏了底层(Fluent NHibernate)并通过一个公开东西给公众IQueryable.
我想过
关于DAL还有什么值得测试的吗?
提前感谢您的回答!
使用web2py DAL,如何创建一个选择记录的查询将在特定字段中为NULL值?
可能重复:
数据抽象层和数据访问层之间有什么区别?
我刚刚在nettuts上阅读了这篇文章.我有点困惑.数据访问层和数据库抽象层之间有什么区别?
另外,我应该为此制作自己的自定义类,还是使用PDO更好?
我有一个DatabaseOps执行所有CRUD操作的类.其他类(例如User)继承自它,并使用此类中的方法来执行CRUD操作.我有另一个名为Databaseopen-connection,close connection,fetch array,确认查询等的类.我应该将它们写入单个类(数据访问/抽象层)吗?哪一个会更好?
我希望我的所有图层BLL,DAL和UI共享类(具体或接口).
这真的是一种不好的做法吗?
我不想从我的DAL方法返回数据表,而是返回BLL可以直接使用的对象.
我希望有一个单独的VS项目,其中包含所有层应该知道的类.
示例:我想定义一个所有层都应该知道的批次类.UI应该能够接收批次类,以便显示或使用户能够提交要处理的批次.此外,DAL应该能够使用批次类查询数据库并返回它们.另一方面,BLL应该获得这些批次并将业务规则应用到它们上.
如果这是完全错误的替代品有哪些?
假设你有相应的类在表中的以下数据Person,什么是搜索空安全地场的串联的正确方法name1和name2?
@Entity
public class Person {
Long id;
String name1;
String name2;
// Getters and setters omitted for brevity
}
Run Code Online (Sandbox Code Playgroud)
id | name1 | name2 ------------------------ 1 | Foo | null 2 | null | Bar 3 | Foo | Bar
默认情况下,两列的连接将导致nullif为null.
public List<String> nameConcatenations() {
JPAQuery q = new JPAQuery(entityManager);
QPerson person = QPerson.person;
StringExpression nameConcatenation = person.name1.concat(person.name2);
return q.from(person).list(nameConcatenation)
}
Run Code Online (Sandbox Code Playgroud)
以上代码导致以下列表:
null
null
FooBar
Run Code Online (Sandbox Code Playgroud) 我的问题是关于3层架构。
我的项目简短地类似于以下内容,但是让我烦恼的是在数据库中插入新列之后,除了BLL之外,我必须更新所有这些字段。在表示层中,我在DAL内以及DAL内创建了一个OBJ,其中有一个SQL查询。我必须手动更新所有这些字段。
如果我以“正常”方式进行操作,则将所有内容放到表示层中,然后全部更新到一个位置。
我是否正确应用了此三层体系结构,使用此分层体系结构有什么优势?
我的第二个问题是:
在DAL中,我通过_view收集数据。我想知道的是,我应该为每个视图编写另一个BOboj吗?我已经有一个BOboj类,但是它不包含所有字段。
插入数据时,我必须使用BOboj,但是,在列出数据时,我使用的是视图,在这种情况下,我应该为每个视图还是其他视图创建另一个BOboj_view类?简便的方法是什么?
例如; 我有20个视图和40个类映射到sql server上的每个表,我的视图收集数据不同的表(这意味着不同的对象)。我应该再创建20个类,除了40个代表视图的类吗?
OBJ
class BOboj {
private int _PId;
private string _Name;
.......
.......
}
Run Code Online (Sandbox Code Playgroud)
DAL
BOboj_DAL {
public bool Add(BOboj obj)
{
using (SqlConnection con = Connect.connect)
{
string sql = "insert into Persons (Id,Name,
.......
.......
}
Run Code Online (Sandbox Code Playgroud)
BBL
BOboj_BLL {
.......
.......
public bool Add(BOboj_DAL obj)
{
BOboj_DAL bb_dal = new BOboj_DAL();
try
{
return bb_dal.Ekle(obj);
}
catch (Exception)
{
throw;
}
finally { bb_dal = null; }
}
....... …Run Code Online (Sandbox Code Playgroud) .net ×3
c# ×3
bll ×2
nhibernate ×2
architecture ×1
asp.net ×1
database ×1
iqueryable ×1
java ×1
layer ×1
model ×1
mysql ×1
null ×1
oop ×1
orm ×1
php ×1
poco ×1
querydsl ×1
unit-testing ×1
web2py ×1