良好的编码实践 [英] Good Coding Practices
问题描述
我的建议架构是这样的：
所以，网站调用业务逻辑，业务规则在那里进行评估。
这样它调用DALFacade，它只是它对上层不可见，无论我们是访问db2还是sql server。
EF DAL，它的一个负责与数据库交谈的人，CODE FIRST Approach。
实体类库是具有poco类的项目。
实用程序它的自我解释，我可能会放置代码，如从活动目录中读取属性。
这里是我的代码，我尽可能简化了
OnePage：
protected void BtnSubmitRequestClick（object sender，EventArgs e ）
{
var ecoBonusWorkflow = new EcoBonusWorkflow
{
IsOnHold = true
};
BusinessLogic.EcoBonusRequestSave（ecoBonusWorkflow）;
}
BUsiness逻辑：
public static class BusinessLogic
{
public static void EcoBonusRequestSave（EcoBonusWorkflow ecoBonusWorkflow）
{
if（true）
{
DalFacade.EcoBonusRequestSave（ecoBonusWorkflow）;
}
}
}
DALFacade：
public static class DalFacade
{
private static readonly UnitOfWork UnitOfWork = new UnitOfWork（）;
public static void EcoBonusRequestSave（EcoBonusWorkflow ecoBonusWorkFlow）
{
UnitOfWork.EcoBonusWorkflowRepository.InsertEcoBonusWorkflow（ecoBonusWorkFlow）;
}
}
然后在EF Dal类库中，我使用传统EF 4.1代码第一个方法。
我也使用了Repository模式和工作单位。
欢迎任何观察。
包含实用程序对我来说似乎很奇怪。其他一切都是以一个非常具体的设置命名的，它应该做什么，那么你有这个含糊的命名的实用程序块。
这不是任何特定的编码标准，但我会避免将'实用程序'并入您的顶级架构尽可能多的。每个项目都有一些名为助手或实用程序的文件夹，最后是一个转储，大量的杂项代码似乎不会立即适用于其他任何地方。这正是技术债务和意大利面条代码开始的方式。
除非您是项目中唯一的开发人员，否则最终会发生任何事情，但无论如何我会避免使它合法化。
此外，在你的快速肮脏的警报中包含静态类。除了静态代码伤害可测试性的事实外，Entity框架不是线程安全。这是由你以线程安全的方式使用的，所以如果你有任何多线程或协同处理，所有的DALFacade将会随机抛出大量的错误，并成为一个巨大的头痛。
我的设计中还没有看到依赖注入的任何补贴，这再次是代码的可测试性。
编辑：好的，这些不是Stack的让步，所以现在是时候介绍依赖注入。
基本上，任何时候直接取决于别的东西，例如当你调用一个静态类时你把这两件事结合在一起。一部分不再可替换，而不修改或替换其他部分。这是一个坏事，因为它使重构和改变了一个非常大的问题。你想要做的是松散地耦合这些依赖关系，这样你可以在不破坏所有东西的情况下改变零件。在C＃/ .NET中，你大多是用接口来实现的。
所以，而不是直接使用DALFacade来传递它， ：
interface IDalFacade
{
int DoAThing（）;
bool DoAnotherThing（）;
}
class DalFacade：IDalFacade
{
public int DoAThing（）
{
return 0;
}
public bool DoAnotherThing（）
{
return false;
}
}
然后，您可以在业务逻辑中使用它：
class BusinessLogic：IBusinessLogic
{
public IDalFacade DalFacade {get;私人集合}
public BusinessLogic（）：this（new DalFacade（））
{}
public BusinessLogic（IDalFacade dalFacade）
{
this.DalFacade = dalFacade;
}
public void LogicTheThings（）
{
this.DalFacade.DoAThing（）;
}
}
现在不再重要，如果DalFacade完全被丢弃或如果突然间你们需要两个不同的东西。甚至是真的，如果一个DalFacade甚至通过，只要它符合IDalFacade合同，这是非常好的。你仍然可以调用它没有参数（它只是假定一个具体的实现），但即使这不是理想的。理想情况下，您需要使用依赖注入库，例如 Ninject 或 StructureMap ，这将允许您更容易地进行任何具体的更改。
这在尝试单元测试你的代码，因为，正如我所说，你甚至不需要一个实际的DalFacade来做事情。您可以简单地嘲笑填写IDalFacade合约的内容（使用 RhinoMocks ），然后您可以将所有代码完全独立于项目中的其他任何代码。
I am working on my 2nd project with Entity Framework and I would like to read some opinions about if the code below its good coding practice of not.
My proposed architecture is this:
So, the website calls the business logic, business rules are evaluated there. THen it calls the DALFacade, its just that its invisible for the upper layers whether if we are accessing db2 or sql server.
The EF DAL, its the one in charge of talking with database, CODE FIRST Approach. The entities class library is the project with the poco classes. Utilities its self explanatory, I might put there code like reading properties from active directory.
SO here is my code, I simplified it as much as I could
OnePage:
protected void BtnSubmitRequestClick(object sender, EventArgs e)
{
var ecoBonusWorkflow = new EcoBonusWorkflow
{
IsOnHold = true
};
BusinessLogic.EcoBonusRequestSave(ecoBonusWorkflow);
}
BUsiness Logic:
public static class BusinessLogic
{
public static void EcoBonusRequestSave(EcoBonusWorkflow ecoBonusWorkflow)
{
if (true)
{
DalFacade.EcoBonusRequestSave(ecoBonusWorkflow);
}
}
}
DALFacade:
public static class DalFacade
{
private static readonly UnitOfWork UnitOfWork = new UnitOfWork();
public static void EcoBonusRequestSave(EcoBonusWorkflow ecoBonusWorkFlow)
{
UnitOfWork.EcoBonusWorkflowRepository.InsertEcoBonusWorkflow(ecoBonusWorkFlow);
}
}
Then in the EF Dal class library I use the traditionary EF 4.1 Code First Approach. I used also Repository Pattern and Unit of Work.
Any observation is welcomed
The inclusion of 'utilities' seems very strange to me. Everything else is decently well named with a pretty specific setup of what exactly it should do, then you have this vaguely named block of 'utilities'.
This isn't any particular coding standard, but I would avoid incorporating 'utilities' into your top level architecture as much as you possibly can. Every project has some folder like that named 'helpers' or 'utilities' and it ends up being a dump for a large amount of miscellaneous code that doesn't seem like it immediately fits anywhere else. This is exactly the way technical debt and spaghetti code begins.
It will probably end up happening no matter what you present unless you are the only developer on the project, but nevertheless I'd avoid legitimizing it.
Also, the inclusion of static classes in your quick-and-dirty alarms me. Aside from the fact that static code hurts testability, the Entity framework is not thread-safe. It is up to you to use it in a thread-safe way, so if you have any multithreading or co-processing going on at all your DALFacade is going to randomly throw a ton of errors and be a gigantic headache.
I also don't see any allowance for dependency injection in your design, which again goes to how testable the code is.
EDIT: OK, these were not concessions for Stack, so it's time to introduce the idea of dependency injection.
Basically, any time you make something directly depend on something else, such as when you invoke a static class, you are tying these two things together. One part is no longer replaceable without also modifying or replacing the other part. This is A Bad Thing, because it makes refactoring and changes a very large problem. What you want to do instead is to 'loosely couple' these dependencies so you can change parts out without breaking everything. In C#/.NET, you mostly do this with interfaces.
So instead of having "DALFacade" and passing it around directly, you would instead have something to the effect of:
interface IDalFacade
{
int DoAThing();
bool DoAnotherThing();
}
class DalFacade : IDalFacade
{
public int DoAThing()
{
return 0;
}
public bool DoAnotherThing()
{
return false;
}
}
You may then use it in your business logic like so:
class BusinessLogic : IBusinessLogic
{
public IDalFacade DalFacade { get; private set; }
public BusinessLogic() : this(new DalFacade())
{}
public BusinessLogic(IDalFacade dalFacade)
{
this.DalFacade = dalFacade;
}
public void LogicTheThings()
{
this.DalFacade.DoAThing();
}
}
It now no longer matters if DalFacade gets completely trashed or if all of a sudden you need two of them for different things. Or even, truly, if a DalFacade is even passed in. As long as it fulfills the IDalFacade contract, it's perfectly fine. You can still call it with no parameters (it just assumes a specific implementation), but even this is not ideal. Ideally you would want to use a dependency injection library, such as Ninject or StructureMap, which would allow you to make any specific changes even more easily.
This is also useful when attempting to unit test your code, since, as I said, you don't even need an actual DalFacade to do things. You can simply mock out something that fills the IDalFacade contract (using something like RhinoMocks), and you can then test all your code totally separately from anything else in your project.
这篇关于良好的编码实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
