Questions tagged «layers»

层(或抽象级别或抽象层)是一种隐藏特定功能集的实现细节的方法。

12
“业务逻辑应该在服务中而不在模型中”的准确性如何?
情况 今天晚上早些时候,我回答了关于StackOverflow的问题。 问题: 现有对象的编辑应该在存储层还是在服务中进行? 例如,如果我有一个负债的用户。我想改变他的债务。我应该通过获取对象,对其进行编辑并保存来在UserRepository或服务(例如BuyingService)中进行操作吗? 我的答案: 您应该将将一个对象变异为相同的对象,并使用存储库来检索该对象。 情况示例: class User { private int debt; // debt in cents private string name; // getters public void makePayment(int cents){ debt -= cents; } } class UserRepository { public User GetUserByName(string name){ // Get appropriate user from database } } 我收到的评论: 业务逻辑实际上应该在服务中。不在模型中。 互联网怎么说? …

13
为什么“较低”的应用程序层不了解“较高”的层是一个好主意?
在典型的(设计良好的)MVC Web应用程序中,数据库不知道模型代码,模型代码不知道控制器代码,并且控制器代码不知道视图代码。(我想您甚至可以从硬件开始甚至更远的地方开始,而且模式可能相同。) 换个方向,您只能向下移动一层。视图可以知道控制器,但不能知道模型。控制器可以知道模型,但不能知道数据库;该模型可以识别数据库,但不能识别操作系统。(更深层次的内容可能无关紧要。) 我可以直观地理解为什么这是一个好主意,但我无法明确表达。为什么这种单向分层样式是个好主意?

3
Bob叔叔的干净架构-每层都有一个实体/模型类?
背景 : 我试图在我的Android应用程序中使用Bob叔叔的干净架构。我研究了许多开源项目,这些项目试图展示正确的方法,并且发现了一个基于RxAndroid 的有趣实现。 我注意到的是: 在每一层(表示,域和数据)中,都有一个用于同一实体的模型类(正在谈论UML)。另外,每当数据越过边界(从层到另一层)时,都有一些映射器类负责对象的转换。 题 : 当我知道如果需要所有CRUD操作时,它们都将具有相同的属性,是否需要在每个层中都有模型类?还是使用干净的体系结构是规则还是最佳实践?


2
在Android开发中使用ORM是否有意义?
在Android开发中使用ORM是否有意义,还是针对UI和DB层之间更紧密的耦合而优化了框架? 背景:我刚刚开始进行Android开发,而我的第一个直觉(来自.net背景)是寻找一个小型的对象关系映射器以及其他有助于减少样板块的工具(例如POJOs + OrmLite + Lombok)。 但是,在开发第一个玩具应用程序时,我偶然发现了一个UI类,该类明确需要数据库游标:AlphabetIndexer。这让我怀疑Android库是否不适合UI和DB层的严格分离,如果我尝试在所有地方使用POJO(而不是直接访问数据库),我会错过许多有用的,省时的功能)。 澄清:我很清楚总体上使用ORM的优势,我特别感兴趣的是Android类库与之一起发挥的作用。

7
从GUI开始构建应用程序是否有用?
应用程序设计和开发的趋势似乎始于“胆量”:领域,然后是数据访问,然后是基础结构等。GUI似乎通常会在此过程的后期出现。我想知道首先构建GUI是否有用... 我的基本原理是,通过至少构建一个原型GUI,您可以更好地了解幕后需要做什么,因此可以更好地开始在域和支持代码上进行工作。 我可以看到这种做法的问题在于,如果尚未编写支持代码,那么GUI层实际上就不会做很多事情。也许构建模拟对象或一次性类(有点像在单元测试中所做的那样)将提供足够的基础来最初构建GUI。 对于实际项目,这可能是可行的想法吗?也许我们可以将GDD(GUI驱动开发)添加到首字母缩写稳定...

3
分层架构中的验证和授权
我知道您在思考(或大喊大叫),“不是另一个问题,它要求验证在分层体系结构中属于什么?!?” 好吧,是的,但是希望这会在这个问题上有所不同。 我坚信验证的形式多种多样,是基于上下文的,并且在体系结构的每个级别都有所不同。这是后期的基础-有助于确定应在每个层中执行哪种类型的验证。另外,经常出现的一个问题是授权检查在哪里。 示例场景来自餐饮业务的应用程序。白天,司机可能会不定期地将卡车上载到现场的任何多余现金上交办公室。该应用程序允许用户通过收集驾驶员的ID和金额来记录“现金下降”。这是一些基本代码来说明涉及的层: public class CashDropApi // This is in the Service Facade Layer { [WebInvoke(Method = "POST")] public void AddCashDrop(NewCashDropContract contract) { // 1 Service.AddCashDrop(contract.Amount, contract.DriverId); } } public class CashDropService // This is the Application Service in the Domain Layer { public void AddCashDrop(Decimal amount, Int32 driverId) …

4
在分层软件体系结构中,同一层的对象之间具有依赖关系是否有问题?
考虑到具有n层体系结构和依赖项注入的中型软件,我很高兴地说属于一个层的对象可以依赖于较低层的对象,而不能依赖于较高层的对象。 但是我不确定要考虑那些依赖同一层其他对象的对象。 举个例子,我们假设一个应用程序具有三层和几个对象,如图像中的一个。显然,自上而下的依赖关系(绿色箭头)没问题,自下而上的依赖关系(红色箭头)不行,但是同一层内的依赖关系(黄色箭头)又如何呢? 除了循环依赖之外,我很好奇其他可能出现的问题以及这种情况下违反了多层体系结构的程度。

3
实体框架和层分离
我正在尝试与Entity Framework一起工作,但遇到了有关层分离的问题。 我通常使用UI-> BLL-> DAL方法,我想知道如何在这里使用EF。 我的DAL通常是这样的 GetPerson(id) { // some sql return new Person(...) } BLL: GetPerson(id) { Return personDL.GetPerson(id) } 用户界面: Person p = personBL.GetPerson(id) 现在的问题是:由于EF创建了我的模型和DAL,将EF包装在我自己的DAL中是一个好主意还是只是浪费时间? 如果不需要包装EF,我仍然可以将Model.esmx放置在其自己的类库中,还是将其放置在BLL中并在其中工作是可以的吗? 我真的看不出将EF包装在我自己的DAL中的原因,但是我想知道其他人在做什么。 因此,除了上述内容之外,我将省略DAL并执行以下操作: BLL: GetPerson(id) { using (TestEntities context = new TestEntities()) { var result = from p in context.Persons.Where(p => p.Id = …

1
洋葱架构与3层架构
我看到洋葱架构仅比BL负责在DAL(或DAL的接口)上调用方法进行CRUD的3层架构有所益处。洋葱具有更好的关注点分离,可测试性,可维护性,并且更清洁。 那么,洋葱架构在各个方面是否确实更好,并且3层架构只是做事的一种旧方法,或者在某些情况下,我更喜欢使用3层架构,如果这样-哪个?

3
DDD中的Presentation VS Application层
我在域驱动设计中的表示层和应用程序层之间划清界限时遇到麻烦。 控制器,视图,布局,Javascript和CSS文件应该放在哪里? 是在应用程序层还是表示层中? 如果它们都放在同一层,那么包含另一层的是什么?是空的吗?

2
GUI,BLL,DAL组织在项目中
我正在阅读有关应用程序层的内容,并希望在我的下一个项目(C#、. Net)中使用此设计。一些问题: 是否通过名称空间完成层分离?Project.BLL。什么,Project.DAL。什么 按层然后按组件(Project.BLL.Component1)或按组件再按层(Project.Component1.BLL)分离是否更合适 对于我的DAL,是否使用不同的类进一步组织了这一层?如果所有数据库调用都放在一个类中,则没有组织。用不同的类或名称空间将它们拆分会更好吗? DAL类通常是静态的吗?在每次调用其方法之一之前实例化DAL对象似乎很麻烦。 用这些层以正确的方式处理事务的任何其他技巧将不胜感激。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.