business-logic

问题 Below picture is a simple part of complex algorithm. I try to prepare some classes in accordance with algorithm. abstract class Person { public string HasXRecords { get; set; } public int PersonAnotherFeature { get; set; } public List<X> Xs { get; set; } = new List<X>(); } abstract class X { //There will more than 1000 type subX classes } interface IAdder { void AddXToList(); } interface IRemover { void RemoveXFromList(); } class XAdderFactory { private Person _person; public bool

问题 I am working on a project using entity framework. Is it okay to use partial classes of the EF generated classes as the business layer. I am begining to think that this is how EF is intended to be used. I have attempted to use a DTO pattern and soon realized that i am just creating a bunch of mapping classes that is duplicating my effort and also a cause for more maintenance work and an additional layer. I want to use self-tracking-entities and pass the EF entities to all the layers. Please

问题 I would like some advice on how to separate the UI and business logic in a simple C# Windows Forms Application. Let's take this example: The UI consists of a simple textbox and a button. The user enters a number between 0 and 9 and clicks the button. The program should add 10 to the number and update the text box with that value. The business logic part should have no idea of the UI. How can this be accomplished? Here's the empty Process class (Business Logic): namespace addTen { class

问题 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 . I have a team lead who seems to think that business logic is very subjective, to the point that if my stored procedure has a WHERE ID

问题 I hate to ask the classic question of "business logic in database vs code" again, but I need some concrete reasons to convince an older team of developers that business logic in code is better, because it's more maintainable, above all else. I used to have a lot of business logic in the DB, because I believed it was the single point of access. Maintenance is easy, if I was the only one doing the changing it. In my experience, the problems came when the projects got larger and complicated.

问题 I have a class : Schedule. public class Schedule { private int locationNum; private int cost; private String costReason; private Date weekOfChange; private Date dayOfChange; private String changeReason; // and all those getters and setters public Schedule(int locationNum, int cost, String costReason, Date weekOfChange, Date dayOfChange, String changeReason) throws ApplicationException { //change is all or nothing - all attributes are present or none if((weekOfChange!=null && dayOfChange!=null

问题 I wonder, is it bad or good idea to use auto increment primary key as business entity identifier such as Partner Id or Account Number ? Also, what pitfalls I can face if I'll choose that approach? 回答1: I don't think everyone shares the same opinion, but I do think it is bad practice. Passing ID's to the user as the 'key' is bad in my opinion, for a number of reasons: ID's aren't natural to users. They are not talking about project '1474623', they are talking about project 'ABC'. They aren't

问题 With Data Annotations it's now easy to localize error messages using Resource.resx files like this for example: public class Student { . . . [Required(ErrorMessageResourceName ="Required", ErrorMessageResourceType = typeof(StudentResources))] [StringLength(16)] [Display(Name = "FirstName", ResourceType = typeof(StudentResources))] public string FirstName { get; set; } . . . } Now, let's say I want to check if a Student has already made a Payment for a given month and year: public bool

问题 On a site with a reasonable amount of traffic , would it matter if the application/business logic is written as stored procedures ,triggers and views , instead of inside the PHP code itself? What would be the best way to go keeping scalability in mind. 回答1: I can't provide you statistics, but unless you plan to change PHP for another language in the future, i can say keeping the business logic in PHP is more "scalability friendly". Its always easier and cheaper to solve web server load

问题 In trying to understand Domain Driven Design I keep returning to a question that I can't seem to definitively answer. How do you determine what logic belongs to a Domain entity, and what logic belongs to a Domain Service? Example: We have an Order class for an online store. This class is an entity and an aggregate root (it contains OrderItems). Public Class Order:IOrder { Private List<IOrderItem> OrderItems Public Order(List<IOrderItem>) { OrderItems = List<IOrderItem> } Public Decimal