loose-coupling

Lookup API NetBeans Platform + Maven: loosely coupled modules

本小妞迷上赌 提交于 2019-12-14 04:21:59
问题 I'm developing a NetBeans platform application and want to use lookup api to get implementations for specific interfaces, still keeping everything loosely coupled. But the lookup can't find any service provider. Well, I created: a Module (A) that contains two Interfaces (Prot,Com) and a class to show some GUI. a Module (B) that contains an implementation of interface Prot a Module (C) that contains an implementation of interface COM. To register an implementation i used @ServiceProvider

Loose coupling vs tight coupling of services

蓝咒 提交于 2019-12-12 00:56:49
问题 I understand that we at almost all times want to aim for loose coupling between components within an application & why. But in the below example if someone could clarify as to why it isn't tightly coupled when we pass in a service as a parameter to a constructor so I could understand the logic that's going on under the hood. export class Test(){ dataResults; constructor(service: testService){ this.dataResults = service.getData() } } 回答1: Tight coupling means : Code written is dependent on one

How should AutoMapper access my DAL?

感情迁移 提交于 2019-12-11 12:37:39
问题 I have an InvoiceInputModel with a ProjectId property which is a reference to a Project entity. Ideally, I want AutoMapper to be able to map an entire Invoice entity from an InvoiceInputModel , which looks like this: public class InvoiceInputModel { public Guid Id { get; set; } public DateTime Date { get; set; } public string Reference { get; set; } public Guid ProjectId { get; set; } } Obviously the following is bad: Mapper.CreateMap<InvoiceInputModel, Invoice>() .ForMember(src => src

MVC 3 passing entity as an Interface

不羁岁月 提交于 2019-12-10 14:44:42
问题 I'm currently working on an MVC 3 project using Ninject as my DI, the business objects are stored in a separate assembly. I'm running into an issue with the controller parameters, when posting back for CRUD operations I'm getting the error "Cannot create an instance of an interface". I am aware that you can't create an instance of an interface, but it seems like the only way I can get around this is to use a custom model binder and pass the FormCollection through. This seems really messy and

Help with debate on Separation of concerns (Data Access vs Business Logic) [closed]

谁说胖子不能爱 提交于 2019-12-07 21:24:39
问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 5 years ago . I had a debate with my co-worker on whether certain logic belongs in the data access or business logic layer. The scenario is, the BLL needs some data to work with. That data primarily lives in the database. We want to cache that data (using System.Runtime.Caching) so it's

Lua: can I use “require” as a form of dependency injection?

若如初见. 提交于 2019-12-06 12:34:33
I'm designing a hospital integration system which consumes data from various hospitals (our customers), and then applies specific business rules to said data based on reading configurations from a database. If I were using Java, my first instinct would be to build a series of interfaces representing the various business rules, and then inject concrete instances (using Spring/guice) to compose a fully configured object. This would allow me to achieve a clean separation between configuration logic (what biz rules should apply to Hospital Foo?) and the actual business rules themselves.

Help with debate on Separation of concerns (Data Access vs Business Logic) [closed]

允我心安 提交于 2019-12-06 11:04:41
Closed . This question is opinion-based . It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post . Closed 5 years ago . I had a debate with my co-worker on whether certain logic belongs in the data access or business logic layer. The scenario is, the BLL needs some data to work with. That data primarily lives in the database. We want to cache that data (using System.Runtime.Caching) so it's quickly available on subsequent requests. The architecture is such that the DAL and the BLL live on the

Do you define an interface for every public class in your domain model? Pros and Cons? [closed]

笑着哭i 提交于 2019-12-06 04:29:12
问题 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 7 years ago . Do you implement an interface for every public class in your domain model? Pros and Cons? Update: If Repositories interfaces and

Do you define an interface for every public class in your domain model? Pros and Cons? [closed]

烂漫一生 提交于 2019-12-04 11:14:51
Do you implement an interface for every public class in your domain model? Pros and Cons? Update: If Repositories interfaces and domain model classes are defined in separate assemblies, wouldn't there be circular dependency if we do not define interfaces for every domain class. No. Cons. Noise code. More to write. YAGNI. You should define interfaces for dependencies between layers, not for every class. So your Service layer should depend on a repository interface, and your presentation layer should depend on a service interface. Past that, there aren't many hard and fast rules, other then use

Loose Coupling and OO Practices for Beginners

↘锁芯ラ 提交于 2019-12-03 13:19:10
Keeping classes loosely coupled is an important aspect of writing code that is easy to understand, modify, and debug--I get that. As a newbie, though, just about anytime I get beyond the most simple examples I struggle. I understand, more or less, how I can encapsulate strings, integers, and simple data types in classes of their own. When I start dealing with information like rich text formatting, however, things get really complicated--unless I just use the various methods already present in a component. To continue this example, suppose I was writing something that included an RTF memo